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 s
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 val
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
S
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-of
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 de
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
>>>> ---
&
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 inse
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 use th
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-of
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
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 regi
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/c
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 "msic_se
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
("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
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
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 ?
> > >
> >
&
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
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
t;);
> 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 platfor
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 tha
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 platfor
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 tha
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 tha
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 tha
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.
Signed-off-b
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.
Signed-off-b
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.
Signed-off-b
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 don't
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
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 unsubscrib
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 w
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
n the same 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 colli
ix 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
---
drivers/mfd/da9052-core.c | 3 ++-
1 file changed, 2 inser
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
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. Thi
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 beha
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 de
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
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 assig
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 1-2.4:1
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 multi-functio
ell-id for platform devices. Note
that the final patch is a pre-requisite for this.
Johan
[1] http://marc.info/?l=linux-kernel&m=141094514827834&w=2
Johan Hovold (6):
mfd: viperboard: fix platform-device id collision
mfd: rtsx_usb: fix platform device-id collision
mfd: core: add h
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 ?
> > > > [
RE: [PATCH] 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:gr
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
gadget: fsl: Add FSL USB Gadget entry in
> platform device id
>
> On Fri, Mar 14, 2014 at 08:52:19PM +, suresh.gu...@freescale.com
> wrote:
> > Hi,
> > Thanks for reviewing my patches.
> > Please find my comments inline
> >
> > -Original Mes
Gupta Suresh-B42813
> Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Gupta Suresh-B42813
> Subject: Re: [PATCH] usb: gadget: fsl: Add FSL USB Gadget entry in platform
> device id
>
> On Thu, Mar 13, 2014 at 07:35:31PM +
@vger.kernel.org; Gupta Suresh-B42813
Subject: Re: [PATCH] usb: gadget: fsl: Add FSL USB Gadget entry in platform
device id
On Thu, Mar 13, 2014 at 07:35:31PM +0530, Suresh Gupta wrote:
> From: Suresh Gupta
>
> Add FSL USB Gadget entry in platform device id table
why this tab ?
[Sures
On Thu, Mar 13, 2014 at 07:35:31PM +0530, Suresh Gupta wrote:
> From: Suresh Gupta
>
> Add FSL USB Gadget entry in platform device id table
why this tab ?
> Signed-off-by: Suresh Gupta
> ---
> drivers/usb/gadget/fsl_udc_core.c | 2 ++
> 1 file changed, 2 insertions
From: Suresh Gupta
Add FSL USB Gadget entry in platform device id table
Signed-off-by: Suresh Gupta
---
drivers/usb/gadget/fsl_udc_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index b7dea4e..35b20e6
The port number is only local to the ethernet block, not global, so
there can be two ethernet blocks both using the same port, like
kirkwood with both using port 0.
Fix this by using the array index offset for the allocated platform
devices as the id.
Signed-off-by: Jonas Gorski
---
drivers/net
From: Johan Hovold
Add platform device-id table in order to identify the controller and
determine its configuration.
The currently used configuration parameters are:
have_alt_pixclock
- SOC uses an alternate pixel-clock calculation formula (at91sam9g45
non-ES)
have_hozval
- SOC has a
Multiple dwc3 controllers will try to allocate multiple xhci-hcd
interfaces.
Changing platform device IDs from NONE to AUTO to support
such cases.
Signed-off-by: Vivek Gautam
---
drivers/usb/dwc3/host.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/dwc3/ho
On 9/11/2007, "Henrique de Moraes Holschuh" <[EMAIL PROTECTED]> wrote:
>On Tue, 11 Sep 2007, Jean Delvare wrote:
>> I don't know your code and I don't really have the time to look at it
>> in depth, but I'm a bit surprised. Presumably your driver is
>> implementing a number of interfaces (e.g. hwm
On Tue, 11 Sep 2007, Jean Delvare wrote:
> >I will see what I can do about breaking it up in various modules. But this
> >can be unoptimal. If I took it too seriously, thinkpad-acpi would break into
> >at least five different modules, if not more, and at least one or two
> >modules would need to b
Hi Henrique,
On 9/10/2007, "Henrique de Moraes Holschuh" <[EMAIL PROTECTED]> wrote:
>On Sat, 08 Sep 2007, Jean Delvare wrote:
>> * Detection could be moved to user-space entirely, then we would only
>> need a way to instantiate these specific devices from user-space. This
>> exists in other areas
On Sat, 08 Sep 2007, Jean Delvare wrote:
> This more general than just the platform bus. It's how the Linux 2.6
> device driver model is designed.
No issues about that. It is just that the platform bus sucks a bit if you
need to "abuse it" (no wonder!) to hang various different devices that are
p
On Sat, 08 Sep 2007, Jean Delvare wrote:
> On Fri, 7 Sep 2007 17:56:59 -0300, Henrique de Moraes Holschuh wrote:
> > On 9/7/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > > To go one step further, I am questioning the real value of this naming
> > > exception for these "unique" platform devices. O
On Fri, Sep 07, 2007 at 03:35:59PM +0200, Jean Delvare wrote:
> Hi Greg, all,
>
> While platform_device.id is a u32, platform_device_add() handles "-1" as
> a special id value. This has potential for confusion and bugs. One such
> bug was reported to me by David Brownell:
>
> http://lists.lm-sens
On Sat, 8 Sep 2007 00:50:22 -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 07 Sep 2007, David Brownell wrote:
> > > I don't feel like drivers like hdaps, thinkpad-acpi, dock, bay,
> > > and many others really belong in the platform bus. But that's
> > > what happens right now.
> >
> > As a r
On Fri, 7 Sep 2007 17:56:59 -0300, Henrique de Moraes Holschuh wrote:
> On 9/7/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > To go one step further, I am questioning the real value of this naming
> > exception for these "unique" platform devices. On top of the bugs I
> > mentioned above, it has p
On Fri, 07 Sep 2007, David Brownell wrote:
> > The platform for a ThinkPad is either i386 or amd64.
>
> Both i386 and x86_64 are clearly an "arch". They even live in
> an "arch" directory: linux/arch/{i386,x86_64}.
Well, I stand corrected on the "platform" term, then.
> When folk talk about a
> > (Also, note that "platform", "host", and "board" are ambiguous.
> > In some contexts each is synonymous; in others, not. I avoid
>
> In this specific case I am talking about, they're not.
That is, in *YOUR* usage context they're not. I had to parse
what you wrote a few times before your comm
On Fri, 07 Sep 2007, David Brownell wrote:
> > > For that matter, a *driver* should never create its own device node(s)
> > > in the first place. Device creation belongs elsewhere, like as part of
> > > platform setup or, for busses with integral enumeration support like
> > > PCI or USB, bus glue
> > For that matter, a *driver* should never create its own device node(s)
> > in the first place. Device creation belongs elsewhere, like as part of
> > platform setup or, for busses with integral enumeration support like
> > PCI or USB, bus glue. Linux is moving away from that legacy model.
>
>
On Fri, 07 Sep 2007, David Brownell wrote:
> For that matter, a *driver* should never create its own device node(s)
> in the first place. Device creation belongs elsewhere, like as part of
> platform setup or, for busses with integral enumeration support like
> PCI or USB, bus glue. Linux is movi
On Fri, 07 Sep 2007, Dmitry Torokhov wrote:
> On 9/7/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > To go one step further, I am questioning the real value of this naming
> > exception for these "unique" platform devices. On top of the bugs I
> > mentioned above, it has potential for compatibility
> If a device has a . scheme this implies possibility of
> having several instances of said device in a box. There are a few of
> platform devices that can only have one instance
Like USB peripheral controllers. Only one external "B" type
connector is allowed.
> - for example i8042
> keyb
Hi Dmitry,
Thanks for your answer.
On Fri, 7 Sep 2007 10:58:31 -0400, Dmitry Torokhov wrote:
> On 9/7/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > While platform_device.id is a u32, platform_device_add() handles "-1" as
> > a special id value. This has potential for confusion and bugs. One suc
Hi Jean,
On 9/7/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi Greg, all,
>
> While platform_device.id is a u32, platform_device_add() handles "-1" as
> a special id value. This has potential for confusion and bugs. One such
> bug was reported to me by David Brownell:
>
> http://lists.lm-sensors
Hi Greg, all,
While platform_device.id is a u32, platform_device_add() handles "-1" as
a special id value. This has potential for confusion and bugs. One such
bug was reported to me by David Brownell:
http://lists.lm-sensors.org/pipermail/i2c/2007-September/001787.html
And since then I've found
78 matches
Mail list logo
