On Friday 29 January 2016 21:03:40 Sergei Shtylyov wrote:
> On 01/29/2016 07:18 PM, Krzysztof Hałasa wrote:
>
> >> The unclear part here is for IXP4xx, which supports both big-endian
> >> and little-endian configurations. So far, the driver has done
> >> no byteswap in either case. I suspect that
Hello.
On 01/29/2016 07:18 PM, Krzysztof Hałasa wrote:
The unclear part here is for IXP4xx, which supports both big-endian
and little-endian configurations. So far, the driver has done
no byteswap in either case. I suspect that is wrong and it would
actually need to swap in one or the other cas
Hi Clemens,
On Thu, Jan 28, 2016 at 09:46:59AM +0100, Clemens Ladisch wrote:
> Dave Penkler wrote:
> > Implement support for the USB488 defined READ_STATUS_BYTE ioctl (1/5)
> > and SRQ notifications with fasync (2/5) and poll/select (3/5) in order
> > to be able to synchronize with variable duratio
On Friday 29 January 2016 17:18:09 Krzysztof Hałasa wrote:
> Arnd Bergmann writes:
>
> > The unclear part here is for IXP4xx, which supports both big-endian
> > and little-endian configurations. So far, the driver has done
> > no byteswap in either case. I suspect that is wrong and it would
> > a
Arnd Bergmann writes:
> The unclear part here is for IXP4xx, which supports both big-endian
> and little-endian configurations. So far, the driver has done
> no byteswap in either case. I suspect that is wrong and it would
> actually need to swap in one or the other case, but I don't know
> which
Arnd Bergmann writes:
> This addresses both issues by moving all the definitions into the
> pxa25x_udc driver itself. It turns out the only difference between
> them was 'UDCCS_IO_ROF', and that could well be a mistake when it
> was incorrectly copied from pxa25x to ixp4xx.
>
> Signed-off-by: Arn
Stefan,
On Fri, Jan 29, 2016 at 7:28 AM, Stefan Wahren wrote:
> Hi Doug,
>
> Am 27.01.2016 um 21:43 schrieb Doug Anderson:
>> Stefan,
>>
>> On Wed, Jan 27, 2016 at 12:36 PM, Stefan Wahren
>> wrote:
>>> i can only give you feedback from a user perspective. My keyboard and
>>> C-Media
>>> USB Au
On Fri, 29 Jan 2016, Stafford Horne wrote:
> The midi controller times-out while initializing reports, this
> causes boot to take an extra 10 seconds. The device descriptor
> advertises that it has an internal HID device but seems to not
> actually do anything useful.
>
> Signed-off-by: Stafford
Arnd Bergmann writes:
> On Friday 29 January 2016 10:32:07 Robert Jarzmik wrote:
>> > This addresses both issues by moving all the definitions into the
>> > pxa25x_udc driver itself. It turns out the only difference between
>> > them was 'UDCCS_IO_ROF', and that could well be a mistake when it
>>
Hi Doug,
Am 27.01.2016 um 21:43 schrieb Doug Anderson:
> Stefan,
>
> On Wed, Jan 27, 2016 at 12:36 PM, Stefan Wahren
> wrote:
>> i can only give you feedback from a user perspective. My keyboard and C-Media
>> USB Audio still works as expected.
> OK, thanks! So you had no problems before my pat
On Fri, 29 Jan 2016, Dan Carpenter wrote:
> Hello Bryan Wu,
>
> The patch c6994e6f067c: "USB: gadget: add USB Audio Gadget driver"
> from Jun 3, 2009, leads to the following static checker warning:
>
> drivers/usb/gadget/function/f_uac1.c:371 f_audio_complete()
> error: __memcpy() '&
(please break your lines at 80 characters ;-)
"B, Ravi" writes:
> Felipe
>
>>hi,
>
>>Ravi Babu writes:
>>> The "no-resource" error occurs when the driver issues DEPSTRTXFER
>>> command to start data transfer on specific endpoint, and dwc3
>
>>this seems to imply that simply sending Start Transf
On Jan 29 2016 or thereabouts, Stafford Horne wrote:
> The midi controller times-out while initializing reports, this
> causes boot to take an extra 10 seconds. The device descriptor
> advertises that it has an internal HID device but seems to not
> actually do anything useful.
>
> Signed-off-by:
The midi controller times-out while initializing reports, this
causes boot to take an extra 10 seconds. The device descriptor
advertises that it has an internal HID device but seems to not
actually do anything useful.
Signed-off-by: Stafford Horne
---
Resending the same patch for the keyboard to
Felipe
>hi,
>Ravi Babu writes:
>> The "no-resource" error occurs when the driver issues DEPSTRTXFER
>> command to start data transfer on specific endpoint, and dwc3
>this seems to imply that simply sending Start Transfer command would trigger
>no-resource which is untrue. The error you mentio
On Fri, 2016-01-29 at 14:10 +0200, Mathias Nyman wrote:
> So everything was fine with 4.4 still?
Yes.
> I just saw that there are changes in PM allowing usb devices to stay suspended
> if we enter suspend with devices runtime suspended, not sure if that has an
> impat.
>
> Was this limited to
Hi folks,
sorry for being so silent lately but there have been some recent changes
which caused me stay away from the list for a while. In summary, I just
moved to another country and I still don't have stable network
connection or time to deal with the list.
I should be around within the next 2
hi,
Ravi Babu writes:
> The "no-resource" error occurs when the driver issues DEPSTRTXFER
> command to start data transfer on specific endpoint, and dwc3
this seems to imply that simply sending Start Transfer command would
trigger no-resource which is untrue. The error you mention happens when
Hello Bryan Wu,
The patch c6994e6f067c: "USB: gadget: add USB Audio Gadget driver"
from Jun 3, 2009, leads to the following static checker warning:
drivers/usb/gadget/function/f_uac1.c:371 f_audio_complete()
error: __memcpy() '&data' too small (4 vs u32max)
drivers/usb/gadget/fun
Hi Dear,
I am Mrs Machiko Kumiko, from Japan, I Have Been Diagnosed with esophageal
Cancer.
I Have Chosen you to distribute my Funds to Charities homes in your Country,
so if you wish to Carry out this humanitarian Work kindly Get back to me for
FURTHER details.
Yours Truely Mrs Machiko Kum
On 28.01.2016 17:05, Oliver Neukum wrote:
Hi,
with the latest kernels I tested devices connected to XHCI
are gone after resume. The ports are not resumed. An error is in dmesg:
[ 614.639506] sd 5:0:0:0: [sdc] Starting disk
[ 614.672568] xhci_hcd :00:14.0: port 7 resume PLC timeout
[ 614.
Arnd Bergmann writes:
> This converts the pxa25x udc driver to use readl/writel as normal
> driver should do, rather than dereferencing __iomem pointers
> themselves.
>
> Based on the earlier preparation work, we can now also pass
> the register start in the device pointer so we no longer need
>
Arnd Bergmann writes:
> This removes the dependency on the mach/hardware.h header file
> from the pxa25x_udc driver after the register definitions were
> already unified in the previous patch.
>
> Following the model of pxa27x_udc (and basically all other drivers
> in the kernel), we define the r
On Friday 29 January 2016 10:32:07 Robert Jarzmik wrote:
> > This addresses both issues by moving all the definitions into the
> > pxa25x_udc driver itself. It turns out the only difference between
> > them was 'UDCCS_IO_ROF', and that could well be a mistake when it
> > was incorrectly copied from
Arnd Bergmann writes:
> ixp4xx and pxa25x both use this driver and provide a slightly
> different set of register definitions for it. Aside from that,
> the definition in the ixp4xx-regs.h header conflicts with the
> on in the pxa27x device driver when compile-testing that:
>
> In file included f
25 matches
Mail list logo
