From: Javier Martinez Canillas <hidden> Date: 2016-02-09 11:08:37
The platform bus_type .match callback attempts to match the platform device
name with an entry on the .id_table if provided and fallbacks to match with
the driver's name if a table is not provided.
Using a platform device ID to match is more explicit, allows the driver to
support more than one device and also the MODULE_DEVICE_TABLE macro can be
used to export the module aliases information instead of the MODULE_ALIAS.
Signed-off-by: Javier Martinez Canillas <redacted>
---
drivers/rtc/rtc-mt6397.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
From: Eddie Huang <eddie.huang@mediatek.com> Date: 2016-02-15 01:58:24
On Tue, 2016-02-09 at 08:08 -0300, Javier Martinez Canillas wrote:
quoted hunk
The platform bus_type .match callback attempts to match the platform device
name with an entry on the .id_table if provided and fallbacks to match with
the driver's name if a table is not provided.
Using a platform device ID to match is more explicit, allows the driver to
support more than one device and also the MODULE_DEVICE_TABLE macro can be
used to export the module aliases information instead of the MODULE_ALIAS.
Signed-off-by: Javier Martinez Canillas <redacted>
---
drivers/rtc/rtc-mt6397.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
This patch looks good to me, but I am wondering, since we tend to use
device tree method to match driver, do we still need support platform
device ID ?
Eddie
This patch looks good to me, but I am wondering, since we tend to use
device tree method to match driver, do we still need support platform
device ID ?
I'm not familiar with neither this IP block nor the SoC so it is up to
you. I just noticed this issue when reviewing a regulator driver for a
similar PMIC posted by someone from mediatek.
I thought platform device was needed since the driver has a MODULE_ALIAS()
but please let me know what you prefer and I can re-spin the patch and
just remove the MODULE_ALIAS() if that makes more sense for this platform.
Eddie
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
This patch looks good to me, but I am wondering, since we tend to use
device tree method to match driver, do we still need support platform
device ID ?
I'm not familiar with neither this IP block nor the SoC so it is up to
you. I just noticed this issue when reviewing a regulator driver for a
similar PMIC posted by someone from mediatek.
I thought platform device was needed since the driver has a MODULE_ALIAS()
but please let me know what you prefer and I can re-spin the patch and
just remove the MODULE_ALIAS() if that makes more sense for this platform.
I agree. We can alway add a MODULE_DEVICE_TABLE() if we get multiple
users of this driver on architectures that don't use devicetree yet.
Arnd
This patch looks good to me, but I am wondering, since we tend to use
device tree method to match driver, do we still need support platform
device ID ?
I'm not familiar with neither this IP block nor the SoC so it is up to
you. I just noticed this issue when reviewing a regulator driver for a
similar PMIC posted by someone from mediatek.
I thought platform device was needed since the driver has a MODULE_ALIAS()
but please let me know what you prefer and I can re-spin the patch and
just remove the MODULE_ALIAS() if that makes more sense for this platform.
I agree. We can alway add a MODULE_DEVICE_TABLE() if we get multiple
users of this driver on architectures that don't use devicetree yet.
Sure. Thanks the patch to add expandability to this driver.
Acked-by: Eddie Huang <eddie.huang@mediatek.com>
Eddie
This patch looks good to me, but I am wondering, since we tend to use
device tree method to match driver, do we still need support platform
device ID ?
I'm not familiar with neither this IP block nor the SoC so it is up to
you. I just noticed this issue when reviewing a regulator driver for a
similar PMIC posted by someone from mediatek.
I thought platform device was needed since the driver has a MODULE_ALIAS()
but please let me know what you prefer and I can re-spin the patch and
just remove the MODULE_ALIAS() if that makes more sense for this platform.
I agree. We can alway add a MODULE_DEVICE_TABLE() if we get multiple
users of this driver on architectures that don't use devicetree yet.
Sure. Thanks the patch to add expandability to this driver.
Acked-by: Eddie Huang <eddie.huang@mediatek.com>
I think we misunderstood one another. I think we can drop both the MODULE_DEVICE_TABLE and the MODULE_ALIAS: there is no need for another
driver ID when it is always probed using DT.
Arnd
This patch looks good to me, but I am wondering, since we tend to use
device tree method to match driver, do we still need support platform
device ID ?
I'm not familiar with neither this IP block nor the SoC so it is up to
you. I just noticed this issue when reviewing a regulator driver for a
similar PMIC posted by someone from mediatek.
I thought platform device was needed since the driver has a MODULE_ALIAS()
but please let me know what you prefer and I can re-spin the patch and
just remove the MODULE_ALIAS() if that makes more sense for this platform.
I agree. We can alway add a MODULE_DEVICE_TABLE() if we get multiple
users of this driver on architectures that don't use devicetree yet.
Sure. Thanks the patch to add expandability to this driver.
Acked-by: Eddie Huang <eddie.huang@mediatek.com>
I think we misunderstood one another. I think we can drop both the MODULE_DEVICE_TABLE and the MODULE_ALIAS: there is no need for another
driver ID when it is always probed using DT.
That's how I understood but then Eddie said the opposite so I got confused
and was waiting for your clarification. I'll re-spin and remove the alias.
Arnd
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America