On Mon, 2015-10-19 at 17:01 -0500, Konstantin Shkolnyy wrote:
> Existing register access functions cp210x_get_config and cp210x_set_config
> are cumbersome to use. This change introduces new functions specifically
> for 16-bit registers that read and write simple u16 values.
Hi,
I am afraid there
Hi
On 10/20/2015 03:28 PM, Peter Chen wrote:
On Tue, Oct 20, 2015 at 03:09:02PM +0900, Jiada Wang wrote:
Hi
On 10/20/2015 03:01 PM, Peter Chen wrote:
On Tue, Oct 20, 2015 at 11:29:18AM +0900, Jiada Wang wrote:
Currently in udc_stop, if vbus_active flag is true, all USB activities
will be sto
On Tue, Oct 20, 2015 at 03:33:52PM +0900, Jiada Wang wrote:
> Hi
>
> On 10/20/2015 03:28 PM, Peter Chen wrote:
> >On Tue, Oct 20, 2015 at 03:09:02PM +0900, Jiada Wang wrote:
> >>Hi
> >>
> >>On 10/20/2015 03:01 PM, Peter Chen wrote:
> >>>On Tue, Oct 20, 2015 at 11:29:18AM +0900, Jiada Wang wrote:
>
hi,
On Mon, 2015-10-19 at 14:25 +0300, Mathias Nyman wrote:
> >>
> >> So basically we are trying to use as many microframes as possible with as
> >> few packets
> >> per microframe as possible.
> >>
> >> Did I understand this correctly?
> > Yes, you are right.
> >
> >> How will devices react if th
On Tue, Oct 20, 2015 at 03:09:02PM +0900, Jiada Wang wrote:
> Hi
>
> On 10/20/2015 03:01 PM, Peter Chen wrote:
> >On Tue, Oct 20, 2015 at 11:29:18AM +0900, Jiada Wang wrote:
> >>Currently in udc_stop, if vbus_active flag is true, all USB activities
> >>will be stopped, but vbus_active flag is stil
Hi
On 10/20/2015 03:01 PM, Peter Chen wrote:
On Tue, Oct 20, 2015 at 11:29:18AM +0900, Jiada Wang wrote:
Currently in udc_stop, if vbus_active flag is true, all USB activities
will be stopped, but vbus_active flag is still left to be true,
this causes issue, when afterwards driver tries to conn
On Mon, Oct 19, 2015 at 07:00:26PM +0300, Vladimir Zapolskiy wrote:
> This change allows to get a driver instance of usb controller, which
> registers an irq, now the interrupt names are unique:
>
> # cat /proc/interrupts | grep ci_
> 72: 0 0 0 0GIC 72 ci_hdr
On Tue, Oct 20, 2015 at 11:29:18AM +0900, Jiada Wang wrote:
> Currently in udc_stop, if vbus_active flag is true, all USB activities
> will be stopped, but vbus_active flag is still left to be true,
> this causes issue, when afterwards driver tries to connect gadget
> device to host, But due to the
Currently in udc_stop, if vbus_active flag is true, all USB activities
will be stopped, but vbus_active flag is still left to be true,
this causes issue, when afterwards driver tries to connect gadget
device to host, But due to the uncleared vbus_active, some necessary
setup steps are skipped.
Thi
On 20.10.2015 00:11, Luis de Bethencourt wrote:
> On 13/10/15 02:49, Krzysztof Kozlowski wrote:
>> 2015-10-09 22:00 GMT+09:00 Luis de Bethencourt :
>>> Since hid_connect() only cares about hiddev_connect() succeeding or
>>> failing, there is no need for this function to return an int and it can
>>>
On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux
wrote:
> On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
>> Hello,
>>
>> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
>> > It's a bit ironic that you've chosen GPIO as an example there. The
>>
On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki wrote:
> On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse
>> wrote:
>> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> >> > But the point I'm making is that we are working
This patch can only be applied after the patch titled
"USB: serial: cp210x: Implement 16-bit register access functions"
Work around 2 cp2108 bugs:
1) cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped.
However, SET_LINE_CTL functions properly. When the driver tries to modify
th
Existing register access functions cp210x_get_config and cp210x_set_config
are cumbersome to use. This change introduces new functions specifically
for 16-bit registers that read and write simple u16 values.
Signed-off-by: Konstantin Shkolnyy
---
drivers/usb/serial/cp210x.c | 119 +++
On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse wrote:
> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> > But the point I'm making is that we are working towards *fixing* that,
> >> > and *not* using DT-specific code in pl
Hello,
On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
> It's a bit ironic that you've chosen GPIO as an example there. The
> "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> gpio descriptor. There's no of_* method.
Without following all that fwnod
On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
> > It's a bit ironic that you've chosen GPIO as an example there. The
> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
>
On Sat, Oct 17, 2015 at 8:19 AM, Rob Herring wrote:
> On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson wrote:
>> Hi,
>>
>> I've bisected boot failures in next-20151016 down to patches in this branch:
>>
>> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
>> wrote:
>>> Tomeu Vizoso (20):
>>> dr
On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - possibly augmenting that with reports
John,
On Fri, Oct 16, 2015 at 9:14 PM, John Youn wrote:
> I reviewed this some more and I think this should be ok. Most of
> the handlers don't make sense without a qtd and/or channel.
>
> Although I am not completely sure on the desc dma case. I think
> it will at least be better than letting th
Hi Russell,
On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
wrote:
>> > What you can do is print those devices which have failed to probe at
>> > late_initcall() time - possibly augmenting that with reports from
>> > subsystems showing what resources are not available, but that's only
>
On 10/16/2015 03:29 AM, Rajmohan Mani wrote:
> From: Rajmohan Mani
>
> Existing Intel xHCI controllers require a delay of 1 mS,
> after setting the CMD_RESET bit in command register, before
> accessing any HC registers. This allows the HC to complete
> the reset operation and be ready for HC regi
On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse wrote:
> On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> > But the point I'm making is that we are working towards *fixing* that,
>> > and *not* using DT-specific code in places where we should be using the
>> > generic APIs.
>>
>> What is
On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> > > But the point I'm making is that we are working towards *fixing* that,
> > > and *not* using DT-specific code in places where we should be using the
> > > generic APIs.
> >
This change allows to get a driver instance of usb controller, which
registers an irq, now the interrupt names are unique:
# cat /proc/interrupts | grep ci_
72: 0 0 0 0GIC 72 ci_hdrc.0
75:2096 0 0 0GIC 75 ci_hdrc.1
Signed-off
On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> I don't know that there *is* a coherent plan here to address it all.
>
> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and pr
On Mon, Oct 19, 2015 at 05:00:54PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 16:30, Russell King - ARM Linux
> wrote:
> > I typically see one or two, maybe five maximum on the platforms I have
> > here, but normally zero.
>
> Hmm, I have given a look at our lava farm and have seen 2 doze
On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> > But the point I'm making is that we are working towards *fixing* that,
> > and *not* using DT-specific code in places where we should be using the
> > generic APIs.
>
> What is the plan for fixing things here? It's not obvious (at least to
On 13/10/15 02:49, Krzysztof Kozlowski wrote:
> 2015-10-09 22:00 GMT+09:00 Luis de Bethencourt :
>> Since hid_connect() only cares about hiddev_connect() succeeding or
>> failing, there is no need for this function to return an int and it can
>> return a bool instead.
>
> It can return bool but it
On 19 October 2015 at 16:30, Russell King - ARM Linux
wrote:
> On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
>> On 19 October 2015 at 15:18, Russell King - ARM Linux
>> wrote:
>> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> >> ... If a device is available and
On Mon, Oct 19, 2015 at 01:47:50PM +0100, David Woodhouse wrote:
> On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
> > See version 2 of the series[1] which did that. It became obvious that
> > was pointless because the call paths ended up looking like this:
> > Generic subsystem code -> DT
On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 15:18, Russell King - ARM Linux
> wrote:
> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
> >> ... If a device is available and has
> >> a compatible driver, but it cannot be probed because a dep
Mian Yousaf Kaukab writes:
> Defect 7374 workaround enables all GPEP as endpoint 0. Restore
> endpoint number when defect 7374 workaround is disabled. Otherwise,
> check to match USB endpoint number to hardware endpoint number in
> net2280_enable() fails.
>
> Cc: # 4.2
> Reported-by: Paul Jones
Defect 7374 workaround enables all GPEP as endpoint 0. Restore
endpoint number when defect 7374 workaround is disabled. Otherwise,
check to match USB endpoint number to hardware endpoint number in
net2280_enable() fails.
Cc: # 4.2
Reported-by: Paul Jones
Signed-off-by: Mian Yousaf Kaukab
---
Hi
Hi,
Geert Uytterhoeven writes:
> This header file will be removed soon.
>
> Signed-off-by: Geert Uytterhoeven
do you wanna take this with the other patches in the series ? I'm fine
with that:
Acked-by: Felipe Balbi
> ---
> Please schedule for v4.3, or provide an Ack, so it can go in through
Hi,
John Youn writes:
> On 10/15/2015 8:32 AM, Felipe Balbi wrote:
>>
>> Hi guys,
>>
>> it's already -rc5 and I need to close my tree for this merge
>> window. Major fixes will still be queued. I still have 3 patches on DWC2
>> pending John's Ack, so those are the last ones which will get into
On 19 October 2015 at 15:18, Russell King - ARM Linux
wrote:
> On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> ... If a device is available and has
>> a compatible driver, but it cannot be probed because a dependency
>> isn't going to be available, that's an error and is going to
On Mon, Oct 19, 2015 at 4:14 AM, Oliver Neukum wrote:
> On Thu, 2015-10-15 at 17:06 -0500, Konstantin Shkolnyy wrote:
>> cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped.
>> However, SET_LINE_CTL functions properly. When the driver tries to modify
>> the register, it reads it,
On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
> ... If a device is available and has
> a compatible driver, but it cannot be probed because a dependency
> isn't going to be available, that's an error and is going to cause
> real-world problems unless the device is redundant. Current
On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
>
> > Certainly, if it literally is adding of_* calls then that would seem to
> > be gratuitously firmware-specific. Nothing should be using those these
> > days; any new code should be using the generic device property APIs
> > (except in spec
On Mon, Oct 19, 2015 at 4:44 AM, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
>> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Gr
On 18 October 2015 at 21:53, Mark Brown wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>
>> > > I can't see adding calls like this a
So basically we are trying to use as many microframes as possible with as few
packets
per microframe as possible.
Did I understand this correctly?
Yes, you are right.
How will devices react if they expect to get 16 packets every 16th microframe,
but they get one packet every microframe inste
On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> > Do you mean firmware rather than bus here? I think that's the confusion
> > I have...
> Certainly, if it literally is adding of_* calls then that would seem to
> be gratuit
On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> > On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > > On Fri, Oct 16, 2015 at 11:57:50P
On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>
> > > > I can't see adding calls li
On Thu, 2015-10-15 at 17:06 -0500, Konstantin Shkolnyy wrote:
> cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped.
> However, SET_LINE_CTL functions properly. When the driver tries to modify
> the register, it reads it, modifies some bits and writes back. Because the
> read byte
Hi Greg,
> Sent: Saturday, October 17, 2015 3:38 PM
>
> On Wed, Oct 07, 2015 at 08:38:53PM +0900, Yoshihiro Shimoda wrote:
> > This patch adds an xhci->priv field for storing the of_device_id.data
> > pointer. This will simplify the code to match platform specific
> > variables (e.g. platform typ
Hi,
On Tue, Jun 23, 2015 at 01:01:09AM +0300, Ruslan Bilovol wrote:
> This patchset adds independent registration of gadgets
> and gadget drivers to udc-core. This is very useful for
> built-in modules into kernel case since it's possible
> situation that gadget driver is probing at a time
> when
Implement support for the USB488 defined READ_STATUS_BYTE and SRQ
notifications with ioctl, fasync and poll/select in order to be able
to synchronize with variable duration instrument operations.
Add ioctls for other USB488 requests: REN_CONTROL, GOTO_LOCAL and
LOCAL_LOCKOUT.
Add convenience ioc
50 matches
Mail list logo
