On Sun, 21 Jun 2015 21:44:30 +0200
, Stefan Agner
wrote:
> On 2015-06-21 01:49, Peter Stuge wrote:
> > Stefan Agner wrote:
> >> libftdi requires to detach the kernel driver to get access to the device
> >
> > Control transfers ought to be possible without a detach.
>
> Good to know, thanks for
On Tue, Jun 2, 2015 at 2:18 PM, Linus Walleij wrote:
> On Sat, May 30, 2015 at 10:29 PM, Grant Likely
> wrote:
>> On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman
>> wrote:
>
>>>> However is the MFD cell approach acceptable?
>>>
>>> Y
On Tue, 26 May 2015 16:18:54 +0100
, Lee Jones
wrote:
> On Thu, 21 May 2015, Thierry Reding wrote:
>
> > On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> > > On Wed, 20 May 2015, Thierry Reding wrote:
> > > > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > > > On Tue
On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman
wrote:
> On Mon, Jul 07, 2014 at 12:44:28PM +0200, Linus Walleij wrote:
>> On Fri, Jun 13, 2014 at 8:31 PM, Greg Kroah-Hartman
>> wrote:
>> > On Fri, Jun 13, 2014 at 09:25:07AM +0200, Linus Walleij wrote:
>>
>> >> But I also want to bring the dev
Hi Preston,
Are you still maintaining GPIO support for the cp210x driver? I'm
looking at the last set of patches from 2012 that attempted to
mainline it, but it looks like it didn't get anywhere. I'd like to try
again.
Have you looked at CONFIG_GPIO support in the kernel? I think the
biggest comp
On Wed, Oct 1, 2014 at 4:12 PM, Daniel Drake wrote:
> On Wed, Oct 1, 2014 at 12:36 AM, Vivek Gautam
> wrote:
>> One reason i doubt why it could be coming is because we are
>> specifically putting the
>> child after doing everything with it.
>>
>> When we are getting the child node using for_each
On Thu, 19 Sep 2013 22:47:01 +0100, Russell King
wrote:
> AMBA Primecell devices always treat streaming and coherent DMA exactly
> the same, so there's no point in having the masks separated.
>
> Signed-off-by: Russell King
for the drivers/of/platform.c portion:
Acked-by:
On Sun, Aug 11, 2013 at 8:08 PM, Mark Brown wrote:
> I know there's been some discussion of this topic but do we have any
> general consensus on how to handle such things both from a Linux driver
> model point of view and from a DT/ACPI point of view?
There is precedence for describing enumerated
On Tue, 16 Apr 2013 15:48:07 +0530, Kishon Vijay Abraham I
wrote:
> On Tuesday 16 April 2013 01:20 AM, Grant Likely wrote:
> > On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I
> > wrote:
> >> On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
> >&
On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I
wrote:
> Hi,
>
> On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
> > On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I
> > wrote:
> >> The PHY framework provides a set of APIs for the PHY
On Mon, 15 Apr 2013 16:06:37 +0530, Kishon Vijay Abraham I
wrote:
> Hi,
>
> On Monday 15 April 2013 03:50 PM, Grant Likely wrote:
> > On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I
> > wrote:
> >> Added a generic PHY framework that provides a set of
On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I
wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. To obtain a reference to the PHY without
> using
On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I
wrote:
> Added a generic PHY framework that provides a set of APIs for the PHY drivers
> to create/destroy a PHY and APIs for the PHY users to obtain a reference to
> the PHY with or without using phandle. To obtain a reference to the PHY
"samsung-i2s.2", NULL),
> >>>> + OF_DEV_AUXDATA("samsung,exynos4210-ehci", EXYNOS5_PA_EHCI,
> >>>> + "s5p-ehci", NULL),
> >>>
> >>> I'm assuming the above change is temporary. What is l
x 462e5ac..b3b9af1 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -110,6 +110,8 @@ static const struct of_dev_auxdata
> exynos5250_auxdata_lookup[] __initconst = {
> "samsung-i2s.1", NULL),
>
ix compatible strings for the device
for both patches:
Acked-by: Grant Likely
>
> drivers/usb/dwc3/dwc3-exynos.c |2 +-
> drivers/usb/host/ehci-s5p.c|2 +-
> drivers/usb/host/ohci-exynos.c |2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> --
&
On Thu, 08 Nov 2012 12:24:24 +0530, Vivek Gautam
wrote:
> Adding EHCI device tree node for Exynos5250 along with
> the device base adress and gpio line for vbus.
>
> Signed-off-by: Vivek Gautam
> Acked-by: Jingoo Han
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 25
> +++
m/mach-exynos/mach-exynos5-dt.c
> index c03f3dd..303 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -90,6 +90,8 @@ static const struct of_dev_auxdata
> exynos5250_auxdata_lookup[] __initconst = {
> "s5p-ehci", NULL),
> OF_DEV_AU
On Sun, 25 Nov 2012 16:09:31 +0800, Peter Chen wrote:
> On Fri, Nov 23, 2012 at 11:02:13AM +0100, Marc Kleine-Budde wrote:
> > On 11/23/2012 07:53 AM, Peter Chen wrote:
> > > On Wed, Nov 21, 2012 at 03:06:32PM +0100, Michael Grzeschik wrote:
> > >> This adds mx53 as the next user of the usbmisc dr
On Thu, Oct 25, 2012 at 11:58 AM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Oct 25, 2012 at 10:19:19AM +0000, Grant Likely wrote:
>> Felipe Balbi writes:
>>
>> >
>> > we are compiling the driver always with full OTG
>> > capabilities, so that board_m
Felipe Balbi writes:
>
> we are compiling the driver always with full OTG
> capabilities, so that board_mode trick becomes
> useless.
>
> Signed-off-by: Felipe Balbi
This patch breaks ti816x/am3894 support for the MUSB device because the
hardware
doesn't support OTG mode. The driver needs t
On 1/23/08, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 23 January 2008, Grant Likely wrote:
> > The question is about the device structure which used to be provided
> > by the platform device instances and now there just uses the c67x00's
> >
On 1/21/08, Peter Korsgaard <[EMAIL PROTECTED]> wrote:
> >>>>> "Grant" == Grant Likely <[EMAIL PROTECTED]> writes:
>
> Grant> Personally, I'd prefer to see the v3 series picked up now (as I
> Grant> believe all outstanding commen
..3 only). At a quick glance, I didn't
> see any ... other than stuff associated with peripheral mode
> support, which isn't yet proposed for merging. So for the
> moment it looks like v4 is the one to review (and maybe merge).
np. Hopefully in the next day or so I'll get
form_device's created per serial engine are gone.
> > - Gadget driver (WIP)
> >
> > Comments are very much appreciated.
>
> How does this relate to the "v3" patches posted 8-Jan by Grant Likely?
> Is that the "v3" you were referring to?
My v1, v2 and
blish the diff between v3 and this series?
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
26 matches
Mail list logo
