Committer: Marc Zyngier
CommitterDate: Sun, 16 Aug 2020 22:01:19 +01:00
irqchip/ti-sci-inta: Do not store TISCI device id in platform device id field
Even though DT doesn't make active use of id field in platform_device, we cannot
hijack it to store TISCI device id. So create a field in struct
On Wed, 26 Jul 2017, Chen-Yu Tsai wrote:
> From: Quentin Schulz <quentin.sch...@free-electrons.com>
>
> According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
> AXP809 and AXP813 PEK have different values for startup time bits from
> the AXP20X, let's use t
On Wed, 26 Jul 2017, Chen-Yu Tsai wrote:
> From: Quentin Schulz
>
> According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
> AXP809 and AXP813 PEK have different values for startup time bits from
> the AXP20X, let's use the platform device id with the correct values.
From: Quentin Schulz <quentin.sch...@free-electrons.com>
According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
AXP809 and AXP813 PEK have different values for startup time bits from
the AXP20X, let's use the platform device id with the correct values.
Signed-off-by: Quentin
From: Quentin Schulz
According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
AXP809 and AXP813 PEK have different values for startup time bits from
the AXP20X, let's use the platform device id with the correct values.
Signed-off-by: Quentin Schulz
Acked-for-MFD-by: Lee Jones
Signed
On Mon, 17 Jul 2017, Quentin Schulz wrote:
> According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
> AXP809 and AXP813 PEK have different values for startup time bits from
> the AXP20X, let's use the platform device id with the correct values.
>
> Signed-off-by:
On Mon, 17 Jul 2017, Quentin Schulz wrote:
> According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
> AXP809 and AXP813 PEK have different values for startup time bits from
> the AXP20X, let's use the platform device id with the correct values.
>
> Signed-off-by:
n, 17 Jul 2017, Quentin Schulz wrote:
> >>>
> >>>> According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
> >>>> AXP809 and AXP813 PEK have different values for startup time bits from
> >>>> the AXP20X, let's use the platf
n, 17 Jul 2017, Quentin Schulz wrote:
> >>>
> >>>> According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
> >>>> AXP809 and AXP813 PEK have different values for startup time bits from
> >>>> the AXP20X, let's use the platform device
AXP221, AXP223, AXP288, AXP803,
>>>> AXP809 and AXP813 PEK have different values for startup time bits from
>>>> the AXP20X, let's use the platform device id with the correct values.
>>>>
>>>> Signed-off-by: Quentin Schulz <quentin.sch...@free-elec
AXP221, AXP223, AXP288, AXP803,
>>>> AXP809 and AXP813 PEK have different values for startup time bits from
>>>> the AXP20X, let's use the platform device id with the correct values.
>>>>
>>>> Signed-off-by: Quentin Schulz
>>>> ---
>&g
erent values for startup time bits from
> >> the AXP20X, let's use the platform device id with the correct values.
> >>
> >> Signed-off-by: Quentin Schulz <quentin.sch...@free-electrons.com>
> >> ---
> >> drivers/mfd/axp20x.c | 12
erent values for startup time bits from
> >> the AXP20X, let's use the platform device id with the correct values.
> >>
> >> Signed-off-by: Quentin Schulz
> >> ---
> >> drivers/mfd/axp20x.c | 12 ++--
> >> 1 file changed, 6 insertion
Hi Lee,
On 18/07/2017 09:19, Lee Jones wrote:
> On Mon, 17 Jul 2017, Quentin Schulz wrote:
>
>> According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
>> AXP809 and AXP813 PEK have different values for startup time bits from
>> the AXP20X, let's us
Hi Lee,
On 18/07/2017 09:19, Lee Jones wrote:
> On Mon, 17 Jul 2017, Quentin Schulz wrote:
>
>> According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
>> AXP809 and AXP813 PEK have different values for startup time bits from
>> the AXP20X, let's us
On Mon, 17 Jul 2017, Quentin Schulz wrote:
> According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
> AXP809 and AXP813 PEK have different values for startup time bits from
> the AXP20X, let's use the platform device id with the correct values.
>
> Signed-off-by:
On Mon, 17 Jul 2017, Quentin Schulz wrote:
> According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
> AXP809 and AXP813 PEK have different values for startup time bits from
> the AXP20X, let's use the platform device id with the correct values.
>
> Signed-off-by:
According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
AXP809 and AXP813 PEK have different values for startup time bits from
the AXP20X, let's use the platform device id with the correct values.
Signed-off-by: Quentin Schulz <quentin.sch...@free-electrons.com>
---
drive
According to their datasheets, the AXP221, AXP223, AXP288, AXP803,
AXP809 and AXP813 PEK have different values for startup time bits from
the AXP20X, let's use the platform device id with the correct values.
Signed-off-by: Quentin Schulz
---
drivers/mfd/axp20x.c | 12 ++--
1 file
On Mon, Jan 2, 2017 at 5:20 PM, Javier Martinez Canillas
<jav...@osg.samsung.com> wrote:
> Commit 3fca3d3d5075 ("platform-x86: intel_mid_thermal: add msic_thermal
> alias") added a "msic_thermal" entry to the driver's platform device ID
> table since that w
On Mon, Jan 2, 2017 at 5:20 PM, Javier Martinez Canillas
wrote:
> Commit 3fca3d3d5075 ("platform-x86: intel_mid_thermal: add msic_thermal
> alias") added a "msic_thermal" entry to the driver's platform device ID
> table since that was the platform dev name
This driver is only used in the picoxcell platform and this is DT-only.
So only a OF device ID table is needed and there's no need to have a
platform device ID table. This patch removes the unneeded table.
Suggested-by: Arnd Bergmann <a...@arndb.de>
Signed-off-by: Javier Martinez Canilla
This driver is only used in the picoxcell platform and this is DT-only.
So only a OF device ID table is needed and there's no need to have a
platform device ID table. This patch removes the unneeded table.
Suggested-by: Arnd Bergmann
Signed-off-by: Javier Martinez Canillas
---
drivers/crypto
Commit 3fca3d3d5075 ("platform-x86: intel_mid_thermal: add msic_thermal
alias") added a "msic_thermal" entry to the driver's platform device ID
table since that was the platform dev name registered in some platforms
and the only dev in the platform table was "
Commit 3fca3d3d5075 ("platform-x86: intel_mid_thermal: add msic_thermal
alias") added a "msic_thermal" entry to the driver's platform device ID
table since that was the platform dev name registered in some platforms
and the only dev in the platform table was "
Add FSL USB Gadget entry in platform device id table
Signed-off-by: Changming Huang <jerry.hu...@nxp.com>
Signed-off-by: Suresh Gupta <suresh.gu...@nxp.com>
---
drivers/usb/gadget/udc/fsl_udc_core.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/udc/fsl_u
Add FSL USB Gadget entry in platform device id table
Signed-off-by: Changming Huang
Signed-off-by: Suresh Gupta
---
drivers/usb/gadget/udc/fsl_udc_core.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
b/drivers/usb/gadget/udc/fsl_udc_core.c
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
("GPL v2");
MODULE_AUTHOR("Tianping Fang ");
MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
-MODULE_ALIAS("platform:mt6397-rtc");
This patch looks good to me, but I am wondering, since we tend to use
device tree method to match driver, do
;> MODULE_AUTHOR("Tianping Fang <tianping.f...@mediatek.com>");
> > > >> MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
> > > >> -MODULE_ALIAS("platform:mt6397-rtc");
> > > >
> > > > This
gt; MODULE_AUTHOR("Tianping Fang ");
> > > >> MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
> > > >> -MODULE_ALIAS("platform:mt6397-rtc");
> > > >
> > > > This patch looks good to me, but I am wond
ediaTek MT6397 PMIC");
> > >> -MODULE_ALIAS("platform:mt6397-rtc");
> > >
> > > 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
> > > dev
t;);
> > >> -MODULE_ALIAS("platform:mt6397-rtc");
> > >
> > > 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 ?
> > >
> >
&
2");
> >> MODULE_AUTHOR("Tianping Fang <tianping.f...@mediatek.com>");
> >> MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
> >> -MODULE_ALIAS("platform:mt6397-rtc");
> >
> > This patch looks good to me, but I am
L v2");
> >> MODULE_AUTHOR("Tianping Fang ");
> >> MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
> >> -MODULE_ALIAS("platform:mt6397-rtc");
> >
> > This patch looks good to me, but I am wondering, since we tend to use
his 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
si
m 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 f
R("Tianping Fang <tianping.f...@mediatek.com>");
> MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
> -MODULE_ALIAS("platform:mt6397-rtc");
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
> MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
> -MODULE_ALIAS("platform:mt6397-rtc");
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
On Wed, 10 Feb 2016, Javier Martinez Canillas wrote:
> 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 dev
On Wed, 10 Feb 2016, Javier Martinez Canillas wrote:
> 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 dev
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
On Tue, 09 Feb 2016, Javier Martinez Canillas wrote:
> 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 dev
On Tue, 09 Feb 2016, Javier Martinez Canillas wrote:
> 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 dev
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
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
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
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
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
The patch
regulator: mt6397: Add platform device ID table
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours
The patch
regulator: mt6397: Add platform device ID table
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours
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
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
If the cros_ec_dev driver is built as a module, modalias information is
not filled so the module is not autoloaded. Add a platform device table
and use the MODULE_DEVICE_TABLE() macro to export that information in
the module so user-space can match the modalias uevent and autoload it.
If the cros_ec_dev driver is built as a module, modalias information is
not filled so the module is not autoloaded. Add a platform device table
and use the MODULE_DEVICE_TABLE() macro to export that information in
the module so user-space can match the modalias uevent and autoload it.
If the cros_ec_dev driver is built as a module, modalias information is
not filled so the module is not autoloaded. Add a platform device table
and use the MODULE_DEVICE_TABLE() macro to export that information in
the module so user-space can match the modalias uevent and autoload it.
If the cros_ec_dev driver is built as a module, modalias information is
not filled so the module is not autoloaded. Add a platform device table
and use the MODULE_DEVICE_TABLE() macro to export that information in
the module so user-space can match the modalias uevent and autoload it.
If the cros_ec_dev driver is built as a module, modalias information is
not filled so the module is not autoloaded. Add a platform device table
and use the MODULE_DEVICE_TABLE() macro to export that information in
the module so user-space can match the modalias uevent and autoload it.
If the cros_ec_dev driver is built as a module, modalias information is
not filled so the module is not autoloaded. Add a platform device table
and use the MODULE_DEVICE_TABLE() macro to export that information in
the module so user-space can match the modalias uevent and autoload it.
On Tue, 23 Dec 2014, Fabio Estevam wrote:
> On Wed, Dec 10, 2014 at 10:11 AM, Lee Jones wrote:
>
> > My train of thought was that the original configuration has not
> > changed since 2011. I guess other regulators have been recently
> > introduced. Very well, applied to -fixes.
>
> Still
On Tue, 23 Dec 2014, Fabio Estevam wrote:
On Wed, Dec 10, 2014 at 10:11 AM, Lee Jones lee.jo...@linaro.org wrote:
My train of thought was that the original configuration has not
changed since 2011. I guess other regulators have been recently
introduced. Very well, applied to -fixes.
From: Johan Hovold
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit b6684228726cc25551a43f5c0bd9c5f977f10f48 upstream.
Allow more than one viperboard to be connected by registering with
PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE.
The
From: Johan Hovold jo...@kernel.org
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit b6684228726cc25551a43f5c0bd9c5f977f10f48 upstream.
Allow more than one viperboard to be connected by registering with
PLATFORM_DEVID_AUTO instead of
Hi Lee,
On Wed, Dec 10, 2014 at 10:11 AM, Lee Jones wrote:
> My train of thought was that the original configuration has not
> changed since 2011. I guess other regulators have been recently
> introduced. Very well, applied to -fixes.
Still don't see this patch in linux-next.
--
To
Hi Lee,
On Wed, Dec 10, 2014 at 10:11 AM, Lee Jones lee.jo...@linaro.org wrote:
My train of thought was that the original configuration has not
changed since 2011. I guess other regulators have been recently
introduced. Very well, applied to -fixes.
Still don't see this patch in
On Wed, 10 Dec 2014, Mark Brown wrote:
> On Wed, Dec 10, 2014 at 09:46:50AM +, Lee Jones wrote:
> > On Tue, 09 Dec 2014, Fabio Estevam wrote:
>
> > > Tested on a imx53-qsb board, where multiple DA9053 regulators can be
> > > successfully probed.
>
> > Applied for v3.20, thanks.
>
> Fabio
On Wed, Dec 10, 2014 at 09:46:50AM +, Lee Jones wrote:
> On Tue, 09 Dec 2014, Fabio Estevam wrote:
> > Tested on a imx53-qsb board, where multiple DA9053 regulators can be
> > successfully probed.
> Applied for v3.20, thanks.
Fabio was saying that -next is broken which presumably means
directory.
> ...
> [0.137000] da9052 0-0048: mfd_add_devices failed: -17
> [0.138486] da9052: probe of 0-0048 failed with error -17
>
> Based on the fix done by Johan Hovold at commit b6684228726cc255 ("mfd:
> viperboard: Fix platform-device id collision"
failed: -17
[0.138486] da9052: probe of 0-0048 failed with error -17
Based on the fix done by Johan Hovold at commit b6684228726cc255 (mfd:
viperboard: Fix platform-device id collision).
Tested on a imx53-qsb board, where multiple DA9053 regulators can be
successfully probed.
Signed
On Wed, Dec 10, 2014 at 09:46:50AM +, Lee Jones wrote:
On Tue, 09 Dec 2014, Fabio Estevam wrote:
Tested on a imx53-qsb board, where multiple DA9053 regulators can be
successfully probed.
Applied for v3.20, thanks.
Fabio was saying that -next is broken which presumably means that
On Wed, 10 Dec 2014, Mark Brown wrote:
On Wed, Dec 10, 2014 at 09:46:50AM +, Lee Jones wrote:
On Tue, 09 Dec 2014, Fabio Estevam wrote:
Tested on a imx53-qsb board, where multiple DA9053 regulators can be
successfully probed.
Applied for v3.20, thanks.
Fabio was saying that
by Johan Hovold at commit b6684228726cc255 ("mfd:
viperboard: Fix platform-device id collision").
Tested on a imx53-qsb board, where multiple DA9053 regulators can be
successfully probed.
Signed-off-by: Fabio Estevam
---
drivers/mfd/da9052-core.c | 3 ++-
1 file changed, 2 insertions(+),
Based on the fix done by Johan Hovold at commit b6684228726cc255 (mfd:
viperboard: Fix platform-device id collision).
Tested on a imx53-qsb board, where multiple DA9053 regulators can be
successfully probed.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/mfd/da9052-core.c
Make platform-device id table const.
Signed-off-by: Johan Hovold
---
drivers/rtc/rtc-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index dbb88e46c25d..bdee29674589 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc
Make platform-device id table const.
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/rtc/rtc-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index dbb88e46c25d..bdee29674589 100644
--- a/drivers/rtc/rtc-omap.c
On Tue, Oct 07, 2014 at 10:22:58AM +0100, Lee Jones wrote:
> On Fri, 26 Sep 2014, Johan Hovold wrote:
>
> > Hot-pluggable multi-function devices should use PLATFORM_DEVID_AUTO to
> > avoid name collisions on the platform bus.
> >
> > This driver currently uses the USB-device address as an id.
On Fri, 26 Sep 2014, Johan Hovold wrote:
> Make sure to always honour multi-function devices registered with
> PLATFORM_DEVID_NONE (-1) or PLATFORM_DEVID_AUTO (-2) as id base. In this
> case it does not make sense to append the cell id to the mfd-id base and
> potentially change the requested
On Fri, 26 Sep 2014, Johan Hovold wrote:
> Hot-pluggable multi-function devices should use PLATFORM_DEVID_AUTO to
> avoid name collisions on the platform bus.
>
> This driver currently uses the USB-device address as an id. This makes
> name collisions unlikely, but it could still happen if two
On Fri, 26 Sep 2014, Johan Hovold wrote:
> Allow more than one viperboard to be connected by registering with
> PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE.
>
> The subdevices are currently registered with PLATFORM_DEVID_NONE, which
> will cause a name collision on the platform bus when a
On Fri, 26 Sep 2014, Johan Hovold wrote:
Allow more than one viperboard to be connected by registering with
PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE.
The subdevices are currently registered with PLATFORM_DEVID_NONE, which
will cause a name collision on the platform bus when a
On Fri, 26 Sep 2014, Johan Hovold wrote:
Hot-pluggable multi-function devices should use PLATFORM_DEVID_AUTO to
avoid name collisions on the platform bus.
This driver currently uses the USB-device address as an id. This makes
name collisions unlikely, but it could still happen if two
On Fri, 26 Sep 2014, Johan Hovold wrote:
Make sure to always honour multi-function devices registered with
PLATFORM_DEVID_NONE (-1) or PLATFORM_DEVID_AUTO (-2) as id base. In this
case it does not make sense to append the cell id to the mfd-id base and
potentially change the requested
On Tue, Oct 07, 2014 at 10:22:58AM +0100, Lee Jones wrote:
On Fri, 26 Sep 2014, Johan Hovold wrote:
Hot-pluggable multi-function devices should use PLATFORM_DEVID_AUTO to
avoid name collisions on the platform bus.
This driver currently uses the USB-device address as an id. This makes
Hot-pluggable multi-function devices should use PLATFORM_DEVID_AUTO to
avoid name collisions on the platform bus.
This driver currently uses the USB-device address as an id. This makes
name collisions unlikely, but it could still happen if two devices are
connected to separate buses and gets
Allow more than one viperboard to be connected by registering with
PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE.
The subdevices are currently registered with PLATFORM_DEVID_NONE, which
will cause a name collision on the platform bus when a second viperboard
is plugged in:
viperboard
Make sure to always honour multi-function devices registered with
PLATFORM_DEVID_NONE (-1) or PLATFORM_DEVID_AUTO (-2) as id base. In this
case it does not make sense to append the cell id to the mfd-id base and
potentially change the requested behaviour.
Specifically this will allow
ell-id for platform devices. Note
that the final patch is a pre-requisite for this.
Johan
[1] http://marc.info/?l=linux-kernel=141094514827834=2
Johan Hovold (6):
mfd: viperboard: fix platform-device id collision
mfd: rtsx_usb: fix platform device-id collision
mfd: core: add helper fu
for platform devices. Note
that the final patch is a pre-requisite for this.
Johan
[1] http://marc.info/?l=linux-kernelm=141094514827834w=2
Johan Hovold (6):
mfd: viperboard: fix platform-device id collision
mfd: rtsx_usb: fix platform device-id collision
mfd: core: add helper function
Make sure to always honour multi-function devices registered with
PLATFORM_DEVID_NONE (-1) or PLATFORM_DEVID_AUTO (-2) as id base. In this
case it does not make sense to append the cell id to the mfd-id base and
potentially change the requested behaviour.
Specifically this will allow
Allow more than one viperboard to be connected by registering with
PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE.
The subdevices are currently registered with PLATFORM_DEVID_NONE, which
will cause a name collision on the platform bus when a second viperboard
is plugged in:
viperboard
Hot-pluggable multi-function devices should use PLATFORM_DEVID_AUTO to
avoid name collisions on the platform bus.
This driver currently uses the USB-device address as an id. This makes
name collisions unlikely, but it could still happen if two devices are
connected to separate buses and gets
Hi,
On Thu, Mar 20, 2014 at 09:02:52AM -0700, gre...@linuxfoundation.org wrote:
> On Thu, Mar 20, 2014 at 03:01:56PM +, suresh.gu...@freescale.com wrote:
> > > > > > > @@ -2654,6 +2654,8 @@ static const struct platform_device_id
> > > > > fsl_udc_devtype[] = {
> > > > > > > }, {
> > > > > >
On Thu, Mar 20, 2014 at 03:01:56PM +, suresh.gu...@freescale.com wrote:
> > > > > > @@ -2654,6 +2654,8 @@ static const struct platform_device_id
> > > > fsl_udc_devtype[] = {
> > > > > > }, {
> > > > > > .name = "imx-udc-mx51",
> > > > > > }, {
> > > > > > + .name
> > > > > @@ -2654,6 +2654,8 @@ static const struct platform_device_id
> > > fsl_udc_devtype[] = {
> > > > > }, {
> > > > > .name = "imx-udc-mx51",
> > > > > }, {
> > > > > + .name = "fsl-usb2-udc",
> > > >
> > > > why aren't you just using chipidea ?
> > > >
@@ -2654,6 +2654,8 @@ static const struct platform_device_id
fsl_udc_devtype[] = {
}, {
.name = imx-udc-mx51,
}, {
+ .name = fsl-usb2-udc,
why aren't you just using chipidea ?
[SuresH] This is our legacy driver for all
On Thu, Mar 20, 2014 at 03:01:56PM +, suresh.gu...@freescale.com wrote:
@@ -2654,6 +2654,8 @@ static const struct platform_device_id
fsl_udc_devtype[] = {
}, {
.name = imx-udc-mx51,
}, {
+ .name = fsl-usb2-udc,
why
Hi,
On Thu, Mar 20, 2014 at 09:02:52AM -0700, gre...@linuxfoundation.org wrote:
On Thu, Mar 20, 2014 at 03:01:56PM +, suresh.gu...@freescale.com wrote:
@@ -2654,6 +2654,8 @@ static const struct platform_device_id
fsl_udc_devtype[] = {
}, {
.name =
] usb: gadget: fsl: Add FSL USB Gadget entry in
> platform device id
>
> Hi Ramneek,
>
> Do you understand, what Greg want to communicate.
>
>
> Thanks
> SuresH
>
> > -Original Message-
> > From: gre...@linuxfoundation.org [mailto:gre...@linux
vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] usb: gadget: fsl: Add FSL USB Gadget entry in
> platform device id
>
> On Wed, Mar 19, 2014 at 02:25:25PM +, suresh.gu...@freescale.com
> wrote:
> > Hi
> >
> > > -Original Message
m; gre...@linuxfoundation.org; linux-...@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] usb: gadget: fsl: Add FSL USB Gadget entry in
> > platform device id
> >
> > On Fri, Mar 14, 2014 at 08:52:19PM +, suresh.gu...@freescale.com
> > wrot
1 - 100 of 155 matches
Mail list logo
