In file drivers/usb/core/phy.c line 114, ret variable is assigned to
itself. The following error was observed:
kernel/drivers/usb/core/phy.c:114:8: warning: explicitly assigning value of
variable of type 'int' to itself [-Wself-assign] error, forbidden
warning: phy.c:114
This error was found when
Hi Frédéric,
On Thu, Mar 29, 2018 at 09:53:45AM +0200, FRÉDÉRIC PARRENIN wrote:
> The second part now.
I looked at the tables and it seems the dsdt lists two sensors (imx135 and
ov2740) but the rest of the information on how they're connected etc. is
missing. There are no sensor drivers in upstr
Thanks for the responses everyone
> IMHO, considering the amount of Android users, we can merge this into
> composite.c itself. Just make the code depend on CONFIG_ANDROID. Or
> something along the lines of
I suspect that once you see what this entails you won't be so willing :)
The code for han
On 04/06/2018 02:01 AM, Sergei Shtylyov wrote:
> Hello!
>
> On 4/6/2018 1:31 AM, Shuah Khan wrote:
>
>> Validate !rhport < 0 before using it to access port_status array.
>
> Why '!'?
>
I should have explained it better in the commit log.
rhport is set based on input wIndex which could be 0
Alan,
Thank you for your clarification. Indeed I'm missing some details how USB bulk
protocol works.
I will discuss your comments with Keysight & NI, and I hope we may ask you the
one or other question.
Guido
-Original Message-
From: Alan Stern
Sent: Friday, April 06, 2018 4:59 PM
To:
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
commit d2471d4a24dfbff5e463d382e2c6fec7d7e25a09 upstream.
In the earlier commit dad3f793f20f ("usb: dwc2: Make sure we
disconnect the gadget state"), I was trying to fix up the
fact
On Thu, 5 Apr 2018, Guido Kiener wrote:
> > Well, I'm quite happy with the performance of the new ioctl functions
> > for generic read/write and I don't want to start a lengthy discussion
> > here.
> > However I need some expert knowledge and hints about the following
> > questions:
> > 1. We c
On Thu, Apr 05, 2018 at 08:42:57PM -0700, Patong Yang wrote:
> On Wed, Apr 4, 2018 at 11:26 PM, Greg KH wrote:
> > > This same customer is designing a new board to support the same
> transceiver
> > > configurations. Instead of using the BIOS settings, they would like to
> use
> > > a user-space
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
commit d2471d4a24dfbff5e463d382e2c6fec7d7e25a09 upstream.
In the earlier commit dad3f793f20f ("usb: dwc2: Make sure we
disconnect the gadget state"), I was trying to fix up the
fact
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
commit d2471d4a24dfbff5e463d382e2c6fec7d7e25a09 upstream.
In the earlier commit dad3f793f20f ("usb: dwc2: Make sure we
disconnect the gadget state"), I was trying to fix up the
fac
On Fri, 06 Apr 2018, Heikki Krogerus wrote:
> Using reStructuredText literal-block element with ascii-art.
> That prevents the ascii art from being processed as
> reStructuredText.
>
> Reported-by: Masanari Iida
> Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C
> Multiplexers")
The comment in UAC2 clock selector descriptor definition mentions the
bAssocTerminal after baCSourceID[], but it doesn't exist in the actual
definition. Let's correct it.
Fixes: 5dd360ebd832 ("include/linux/usb/audio-v2.h: add more UAC2 details")
Signed-off-by: Takashi Iwai
---
include/linux/us
On 06.04.2018 15:03, Felipe Balbi wrote:
[...]
okay, but we don't... Do you wanna send some patches?
another thing to keep in mind is that we're trying to be a USB-compliant
stack. Gadget Framework was never meant to be a testing ground for the
Host Stack. There are VERY flexible tools design
Hi again,
Felipe Balbi writes:
> Krzysztof Opasiak writes:
A few advantages over a couple options I've considered are that this
mostly
reuses existing functionalities and won't affect users that haven't
enabled
it. Please let me know of any feedbac
Hi,
Krzysztof Opasiak writes:
>>> A few advantages over a couple options I've considered are that this
>>> mostly
>>> reuses existing functionalities and won't affect users that haven't
>>> enabled
>>> it. Please let me know of any feedback on the design or any possible
>>>
On 06.04.2018 14:35, Felipe Balbi wrote:
Hi,
Krzysztof Opasiak writes:
On 06.04.2018 12:18, Felipe Balbi wrote:
Hi,
Krzysztof Opasiak writes:
A few advantages over a couple options I've considered are that this mostly
reuses existing functionalities and won't affect users that haven
Using reStructuredText literal-block element with ascii-art.
That prevents the ascii art from being processed as
reStructuredText.
Reported-by: Masanari Iida
Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C Multiplexers")
Signed-off-by: Heikki Krogerus
---
Changed since v1:
- Usi
Hi,
Krzysztof Opasiak writes:
> On 06.04.2018 12:18, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Krzysztof Opasiak writes:
>>
>>
>>
> A few advantages over a couple options I've considered are that this
> mostly
> reuses existing functionalities and won't affect users that haven't
>>
> Am 06.04.2018 um 12:51 schrieb Heikki Krogerus
> :
>
> Hi Markus,
>
> On Fri, Apr 06, 2018 at 12:03:55PM +0200, Markus Heiser wrote:
There are ways to do this, look at how the v4l2 and I think the drm
subsystems handle ascii art such that "real" drawings end up being
produced.
Hi Markus,
On Fri, Apr 06, 2018 at 12:03:55PM +0200, Markus Heiser wrote:
> >> There are ways to do this, look at how the v4l2 and I think the drm
> >> subsystems handle ascii art such that "real" drawings end up being
> >> produced.
> >
> > Thanks. I did not actually find anything else except us
On 06.04.2018 12:18, Felipe Balbi wrote:
Hi,
Krzysztof Opasiak writes:
A few advantages over a couple options I've considered are that this mostly
reuses existing functionalities and won't affect users that haven't enabled
it. Please let me know of any feedback on the design or any possi
Hi,
Krzysztof Opasiak writes:
>>> A few advantages over a couple options I've considered are that this mostly
>>> reuses existing functionalities and won't affect users that haven't enabled
>>> it. Please let me know of any feedback on the design or any possible
>>> implementation issues.
>>
On 06.04.2018 12:12, Felipe Balbi wrote:
Hi Jerry,
Jerry Zhang writes:
Hi all,
I've been looking for a way to handle custom device targeted control
requests from userspace. This would allow us to move away from needing
kernel patches to implement
https://source.android.com/devices/accessor
Hi Jerry,
Jerry Zhang writes:
> Hi all,
>
> I've been looking for a way to handle custom device targeted control
> requests from userspace. This would allow us to move away from needing
> kernel patches to implement
> https://source.android.com/devices/accessories/aoa. It seems like we are
> clo
> Am 06.04.2018 um 11:11 schrieb Heikki Krogerus
> :
[...]
>> An ascii graphic in typec.rst cause the error.
>
> Thanks for the report. I'm going to propose that we fix this by
> marking the ascii art as comment:
>
> diff --git a/Documentation/driver-api/usb/typec.rst
Hi Jerry,
W dniu 04.04.2018 o 02:04, Jerry Zhang pisze:
Hi all,
I've been looking for a way to handle custom device targeted control
requests from userspace. This would allow us to move away from needing
kernel patches to implement
https://source.android.com/devices/accessories/aoa. It seems l
On Fri, 06 Apr 2018, Heikki Krogerus wrote:
> To prevent processing of ascii art as reStructuredText
> elements, marking it as a comment.
Please don't. This hides the ascii art from the generated documentation.
The right fix is to use a reStructuredText literal block like this:
diff --git a/Doc
On Fri, Apr 06, 2018 at 11:22:29AM +0300, Heikki Krogerus wrote:
> To prevent processing of ascii art as reStructuredText
> elements, marking it as a comment.
I will change this, and use literal-block instead.
> Reported-by: Masanari Iida
> Fixes: bdecb33af34f ("usb: typec: API for controlling U
On Fri, Apr 06, 2018 at 10:30:10AM +0200, Greg KH wrote:
> On Fri, Apr 06, 2018 at 11:15:55AM +0300, Heikki Krogerus wrote:
> > On Fri, Apr 06, 2018 at 09:57:34AM +0200, Greg KH wrote:
> > > On Fri, Apr 06, 2018 at 10:51:09AM +0300, Heikki Krogerus wrote:
> > > > On Fri, Apr 06, 2018 at 12:38:42PM
On Fri, Apr 06, 2018 at 11:15:55AM +0300, Heikki Krogerus wrote:
> On Fri, Apr 06, 2018 at 09:57:34AM +0200, Greg KH wrote:
> > On Fri, Apr 06, 2018 at 10:51:09AM +0300, Heikki Krogerus wrote:
> > > On Fri, Apr 06, 2018 at 12:38:42PM +0900, Masanari Iida wrote:
> > > > After merge following patch d
2018-04-06 14:15 GMT+09:00 Martin Blumenstingl
:
>>
>> When will this be available in Linus' tree? In the current MW?
> this is already available in Linus' tree. the commit for this specific
> patch (#3) is known as 07dbff0ddbd86c
Oh, great! Thank you.
>> Sure, I can send a patch after som
To prevent processing of ascii art as reStructuredText
elements, marking it as a comment.
Reported-by: Masanari Iida
Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C Multiplexers")
Signed-off-by: Heikki Krogerus
---
Documentation/driver-api/usb/typec.rst | 2 +-
1 file changed,
On Fri, Apr 06, 2018 at 09:57:34AM +0200, Greg KH wrote:
> On Fri, Apr 06, 2018 at 10:51:09AM +0300, Heikki Krogerus wrote:
> > On Fri, Apr 06, 2018 at 12:38:42PM +0900, Masanari Iida wrote:
> > > After merge following patch during 4.17 merger period,
> > > make xmldocs start to fail with error.
>
Hello!
On 4/6/2018 1:31 AM, Shuah Khan wrote:
Validate !rhport < 0 before using it to access port_status array.
Why '!'?
Signed-off-by: Shuah Khan
---
drivers/usb/usbip/vhci_hcd.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/usbip/vhci_hcd.c b/driver
On Fri, Apr 06, 2018 at 10:51:09AM +0300, Heikki Krogerus wrote:
> On Fri, Apr 06, 2018 at 12:38:42PM +0900, Masanari Iida wrote:
> > After merge following patch during 4.17 merger period,
> > make xmldocs start to fail with error.
> >
> > [bdecb33af34f79cbfbb656661210f77c8b8b5b5f]
> > usb: typec
On Fri, Apr 06, 2018 at 12:38:42PM +0900, Masanari Iida wrote:
> After merge following patch during 4.17 merger period,
> make xmldocs start to fail with error.
>
> [bdecb33af34f79cbfbb656661210f77c8b8b5b5f]
> usb: typec: API for controlling USB Type-C Multiplexers
>
> Error messages.
> reST mar
36 matches
Mail list logo
