200.
I guess ill have to buy a new one from somewhere, but im
missing the what and the where :)
Sincerely,
Magnus
> [ Please make sure to CC the linux-usb list as well. ]
>
> On Tue, Feb 18, 2014 at 02:57:45AM +0100, Magnus wrote:
> > After plugging in the plexgear adapter into my
s this problem by re-introducing
the check (in either fsl_udc_core.c or core.c) if that is a proper
solution and I can also assist in testing other fixes to the problem.
Thanks, Magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi
On 23 January 2017 at 12:51, Felipe Balbi wrote:
>
> Hi,
>
> Magnus Lilja writes:
>> Hi
>>
>> I tried the fsl_udc_core gadget driver on the i.MX31 PDK board and got a
>> kernel panic (NULL pointer dereference) when connecting the USB cable. I
>&
On 24 January 2017 at 09:52, Felipe Balbi wrote:
>
> Hi,
>
> Magnus Lilja writes:
>>>> I tried the fsl_udc_core gadget driver on the i.MX31 PDK board and got a
>>>> kernel panic (NULL pointer dereference) when connecting the USB cable. I
>>>> had t
Hi
On 24 January 2017 at 11:54, Felipe Balbi wrote:
>
> Hi,
>
> Magnus Lilja writes:
>>> Magnus Lilja writes:
>>>>>> I tried the fsl_udc_core gadget driver on the i.MX31 PDK board and got a
>>>>>> kernel panic (NULL pointer dereference)
On 24 January 2017 at 19:34, Felipe Balbi wrote:
>
> Hi,
>
> Magnus Lilja writes:
>>> Magnus Lilja writes:
>>>>> Magnus Lilja writes:
>>>>>>>> I tried the fsl_udc_core gadget driver on the i.MX31 PDK board and got
>>>>>
4f7e5e1d08 ("usb: gadget: Refactor request completion")
Signed-off-by: Magnus Lilja
Cc: # 3.18+
---
This patch is the result of the discussion in
https://marc.info/?t=14846881971&r=1&w=2
---
drivers/usb/gadget/udc/fsl_udc_core.c | 10 --
1 file changed, 8 insertion
Hi Morimoto-san,
On Thu, Aug 2, 2012 at 9:09 AM, wrote:
>
> Hi Alan, Rafael, Magnus
>
> Thank you for your reply
>
>> The problem is that the ehci-platform driver currently doesn't know
>> anything about clocks or power sources. We need to add that
>> inf
Alan, thanks again for your comments,
[moved to the linux-usb list]
On Jan 26, 2008 1:55 AM, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Sat, 26 Jan 2008, Magnus Damm wrote:
>
> > Alan and David, thanks for your comments.
> >
> > The HCD_LOCAL_MEM code only copies d
course, that
depends on proper USB PHY DT bindings...
Thanks,
/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
i;
> + };
As an example, instead of relying on "renesas,channel0-pci" or
"renesas,channel2-pci" to specify which hard coded software
configuration you want please rework this to expose 3 separate
channels and use DT to point each host controller to the right
channel.
That
lly in software would be
able to switch between USBHS for Function (or maybe Host) and USB PCI
for USB Host on a board where the hardware allows us to do so. I want
to be able to over time improve the kernel and do this without having
to modify the DTS. Actually, I'd like the DTS to show us how we can
switch the hardware.
This is quite different from hard coding one connection in the DTS.
>> Also, it seems almost impossible to represent some USB controllers in DT
>> -- such as USBHS in particular.
I'm not sure if impossible is the word I would pick, but it is indeed
difficult. My opinion is that we cannot rush this kind of development.
It is fine to take shortcuts with platform devices, but with DT we
want to get it right.
>I've spent several days staring at the various USBHS code and I'm going
> to send you a more detailed report on USBHS vs DT issues.
Sure, if that makes you happy, but I'm more interested in patches myself. =)
>>> So this is a NAK on my side. I expect better.
>
>> Thanks for your long awaited feedback.
>
>I'm not convinced that what you're proposing is indeed better though.
Well, I'm looking forward to a better proposal then! =)
Thanks,
/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
hcd)
>
> static int xhci_plat_start(struct usb_hcd *hcd)
> {
> + struct device_node *of_node = hcd->self.controller->of_node;
> +
> + if (of_device_is_compatible(of_node, "renesas,r8a7790-xhci") ||
> + of_device_is_compatible(o
order? In my mind the
expected behavior would be to always use USB 3.0 if it happens to be
available in the hardware, specified in the DTS, enabled by the kernel
configuration and firmware is loadable. Or does some case exist where
it is better to use USB 2.0? I suspect no.
So I wonder if you ha
mware(fw);
>> +
>> + return retval;
>> +}
>> +
>> +/* This function needs to initialize a "phy" of usb before */
>
> initializing a PHY looks like something that the PHY layer should do.
> Why don't you write a PHY driver and teach xhci-core a
On Sat, Jun 28, 2014 at 12:40 AM, Felipe Balbi wrote:
> On Wed, Jun 18, 2014 at 02:15:42PM +0900, Magnus Damm wrote:
>> Hi Felipe,
>>
>> On Fri, Jun 13, 2014 at 11:25 PM, Felipe Balbi wrote:
>> > Hi,
>> >
>> > On Fri, Jun 13, 2014 at 09:20:31PM +0
command.
I have tested that with this patch the described case is handled
successfully. There is an analogous method for .ioctl available from
usb_wwan (as used in option.c) but I conservatively omitted that for
lack of familiarity.
Signed-off-by: Magnus Lynch
---
Apologies for bad formatting
17 matches
Mail list logo
