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
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 Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Thursday, March 13, 2014 8:56
;
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
wrote:
Hi,
Thanks for reviewing my patches.
Please find my comments inline
-Original
-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-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Saturday, March 15
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...@linuxfoundation.org]
Sent: Wednesday, March 19, 2014 10:22 PM
To: Gupta Suresh-B42813
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 ?
[
@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 b42...@freescale.com
Add FSL USB Gadget entry in platform device id table
why this tab
...@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 +0530, Suresh Gupta wrote:
From: Suresh Gupta b42
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 insertio
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
From: Suresh Gupta b42...@freescale.com
Add FSL USB Gadget entry in platform device id table
Signed-off-by: Suresh Gupta b42...@freescale.com
---
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
On Thu, Mar 13, 2014 at 07:35:31PM +0530, Suresh Gupta wrote:
From: Suresh Gupta b42...@freescale.com
Add FSL USB Gadget entry in platform device id table
why this tab ?
Signed-off-by: Suresh Gupta b42...@freescale.com
---
drivers/usb/gadget/fsl_udc_core.c | 2 ++
1 file changed
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
---
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 j...@openwrt.org
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
From: Johan Hovold jhov...@gmail.com
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
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
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 gautam.vi...@samsung.com
---
drivers/usb/dwc3/host.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
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.
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
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
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 (scsi,
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 be there
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. hwmon) and
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
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.
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. On top of the
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
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:
>
>
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
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
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 potential
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 rule, there
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:
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
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
> > 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
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
> 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
>
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
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:
>
>
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
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
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:
If a device has a name.instance 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
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 such
bug
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 breakage:
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 moving
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.
This
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
(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 comments about
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 PC
101 - 155 of 155 matches
Mail list logo
