Re: [PATCH 24/29] drivers: convert iblock_req.pending from atomic_t to refcount_t

[Nicholas A. Bellinger]

Hi Elena,

On Mon, 2017-03-06 at 16:21 +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
>  drivers/target/target_core_iblock.c | 12 ++--
>  drivers/target/target_core_iblock.h |  3 ++-
>  2 files changed, 8 insertions(+), 7 deletions(-)

For the target_core_iblock part:

Acked-by: Nicholas Bellinger 

--
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

Re: Question: Does usbip support USB 3.0?

[Yuyang Du]

Hi Krzysztof,

On Tue, Mar 07, 2017 at 10:25:31AM +0100, Krzysztof Opasiak wrote:
> 
> If it' not some "top secret" device maybe try to send us descriptors
> (lsusb -vd VID:PID)?
 
Pasted at the end. Surprisingly, I don't see isochronous types. Is it
bulk streams?

Thanks,
Yuyang

--

Bus 002 Device 003: ID 8086:0a80 Intel Corp. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize0 9
  idVendor   0x8086 Intel Corp.
  idProduct  0x0a80 
  bcdDevice   14.86
  iManufacturer   1 Intel Corp
  iProduct2 Intel RealSense 3D Camera R200
  iSerial 3 SN_2481003151
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 1677
bNumInterfaces  6
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  126mA
Interface Association:
  bLength 8
  bDescriptorType11
  bFirstInterface 0
  bInterfaceCount 2
  bFunctionClass 14 Video
  bFunctionSubClass   3 Video Interface Collection
  bFunctionProtocol   0 
  iFunction   4 Intel(R) RealSense(TM) 3D Camera (R200) 
Left-Right
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass14 Video
  bInterfaceSubClass  1 Video Control
  bInterfaceProtocol  0 
  iInterface  4 Intel(R) RealSense(TM) 3D Camera (R200) 
Left-Right
  VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype  1 (HEADER)
bcdUVC   1.10
wTotalLength   68
dwClockFrequency   48.00MHz
bInCollection   1
baInterfaceNr( 0)   1
  VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype  2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType  0x0201 Camera Sensor
bAssocTerminal  0
iTerminal   0 
wObjectiveFocalLengthMin  0
wObjectiveFocalLengthMax  0
wOcularFocalLength0
bControlSize  3
bmControls   0x
  VideoControl Interface Descriptor:
bLength28
bDescriptorType36
bDescriptorSubtype  6 (EXTENSION_UNIT)
bUnitID 2
guidExtensionCode {342d6818-2cdd-7340-ad23-7214739a074c}
bNumControl21
bNrPins 1
baSourceID( 0)  1
bControlSize3
bmControls( 0)   0xfd
bmControls( 1)   0xfb
bmControls( 2)   0x7f
iExtension  0 
  VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  3 (OUTPUT_TERMINAL)
bTerminalID 3
wTerminalType  0x0101 USB Streaming
bAssocTerminal  0
bSourceID   2
iTerminal   0 
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass14 Video
  bInterfaceSubClass  2 Video Streaming
  bInterfaceProtocol  0 
  iInterface  4 Intel(R) RealSense(TM) 3D Camera (R200) 
Left-Right
  VideoStreaming Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype  1 (INPUT_HEADER)
bNumFormats 5
wTotalLength  668
bEndPointAddress  134
bmInfo  0
bTerminalLink   3
bStillCaptureMethod 0
bTriggerSupport 0
bTriggerUsage   0
bControlSize1
bmaControls( 0)28
bmaControls( 1)28
bmaControls( 2)28
bmaControls( 3)28
bmaControls( 4)28
  VideoStreaming Interface Descriptor:
bLength28
bDescriptorType36
  

RE: [PATCH v17 2/3] usb: USB Type-C connector class

[Peter Chen]

 
>>> You mean type-C trigger an ACPI event, and this ACPI event can notify
>>> related USB controller driver doing role switch?
>>
>> No (firmware programs the dual-role hw/registers), but never mind.
>> That could be the case.
>>
>>> If it is correct, there is a notifier between type-C and USB
>>> controller driver, how to define this notifier for non-ACPI platform?
>>
>> Once there is a platform with Type-C like that, the problem needs to
>> be solved. However..
>>
 I'm not commenting on Roger's dual role patch series, but I don't
 really think it should be mixed with Type-C. USB Type-C and USB
 Power Delivery define their own ways of handling the roles, and they
 are not limited to the data role only. Things like OTG for example
 will, and actually can not be supported. With Type-C we will have
 competing state machines compared to OTG. The dual-role framework
 may be useful on systems that provide more traditional connectors,
 which possibly have the ID-pin like micro-AB, and possibly also
 support OTG. It can also be something that exist in parallel with the 
 Type-C
>class, but there just can not be any dependencies between the two.

>>>
>>> Yes, there are two independent things. But if the kernel doesn't have
>>> a notifier between type-C message sender (type-c class) and message
>>> receiver (like USB controller driver for role switch or other drivers
>>> for alternate mode message), we had to find some ways at userspace.
>>
>> ..what ever the solution is, it really can't rely on user space.
>>
>
>... and, at least for our application, using extcon for the necessary 
>notifications works
>just fine.
>

I see, that means you have a hardware signal to notify role switch.

Peter
--
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

usb: gadget: uvc: configfs: fails to enumerate in HOST

[Ganesh Biradar]

Hello experts,

I'm working on a project which uses TI OMAP Plus platform. i'm trying
to implement uvc gadget through configfs.

kernel: 4.4

I have setup function and configfs according to configfs gadget.

mount -t debugfs debugfs /mnt/
echo "device" > /mnt/488d.usb/mode
modprobe -v configfs
modprobe -v libcomposite
cd /sys/kernel/config/usb_gadget
mkdir g1
cd g1
echo "0x1d6b" > idVendor
echo "0x0104" > idProduct
mkdir strings/0x409
echo "0123456789" > strings/0x409/serialnumber
echo "TI Inc." > strings/0x409/manufacturer
echo "UVC gadget" > strings/0x409/product
mkdir configs/c.1
mkdir configs/c.1/strings/0x409
echo "Video" > configs/c.1/strings/0x409/configuration
echo 120 > configs/c.1/MaxPower
modprobe -v usb_f_uvc
mkdir functions/uvc.usb0
mkdir -p functions/uvc.usb0/streaming/uncompressed/u/360p
cat < functions/uvc.usb0/streaming/uncompressed/u/360p/dwFrameInterval
66
100
500
EOF
mkdir functions/uvc.usb0/streaming/header/h
cd functions/uvc.usb0/streaming/header/h
ln -s ../../uncompressed/u
cd ../../class/fs
ln -s ../../header/h
cd ../../class/hs
ln -s ../../header/h
cd ../../../control
mkdir header/h
ln -s header/h class/fs
ln -s header/h class/ss
cd ../../../
ln -s functions/uvc.usb0 configs/c.1
echo "488d.usb" > UDC

so for so good  then i will get some kernel log message

configfs-gadget gadget: uvc_function_bind
dwc3 488d.usb: otg: gadget gadget registered

then when i connect my board(device) to PC(host). at host side i
should get some usb device message and type of usb device but no
message.

and at device side i should get

gadget: high-speed config #1: Video
g_webcam gadget: uvc_function_set_alt(0, 0)
g_webcam gadget: uvc_function_set_alt(1, 0)
g_webcam gadget: uvc_function_set_alt(1, 0


but no message comes up.

i have tried gadget mass storage which is working fine. but coming to
uvc gadget it is failing.

upon digging by adding more debug messages.

[  104.360416] [DEBUG] drivers/usb/gadget/function/f_uvc.c : uvc_alloc_inst
[  104.401748] configfs-gadget gadget: uvc_function_bind
[  104.406998] [DEBUG] opts->streaming_maxpacket=1024
[  104.411810] [DEBUG] opts->streaming_interval=1
[  104.418945] [DEBUG] opts->streaming_maxburst=0
[  104.424337] [DEBUG] name: ep1out, mp: 1024
[  104.428452] [DEBUG] name: ep2out, mp: 1024
[  104.432564] [DEBUG] name: ep3out, mp: 1024
[  104.439034] [DEBUG] name: ep4out, mp: 1024
[  104.444031] [DEBUG] name: ep5out, mp: 1024
[  104.448145] [DEBUG] name: ep6out, mp: 1024
[  104.452257] [DEBUG] name: ep7out, mp: 1024
[  104.458735] [DEBUG] name: ep8out, mp: 1024
[  104.463726] [DEBUG] name: ep9out, mp: 1024
[  104.467841] [DEBUG] name: ep10out, mp: 1024
[  104.472039] [DEBUG] name: ep11out, mp: 1024
[  104.478548] [DEBUG] name: ep12out, mp: 1024
[  104.483605] [DEBUG] name: ep13out, mp: 1024
[  104.487806] [DEBUG] name: ep14out, mp: 1024
[  104.492004] [DEBUG] name: ep15out, mp: 1024
[  104.498495] [DEBUG] name: ep1in, mp: 1024
[  104.502523] [DEBUG] uvc->control_ep->address=81
[  104.508669] [DEBUG] name: ep1out, mp: 1024
[  104.513657] [DEBUG] name: ep2out, mp: 1024
[  104.517771] [DEBUG] name: ep3out, mp: 1024
[  104.521882] [DEBUG] name: ep4out, mp: 1024
[  104.528289] [DEBUG] name: ep5out, mp: 1024
[  104.532405] [DEBUG] name: ep6out, mp: 1024
[  104.538083] [DEBUG] name: ep7out, mp: 1024
[  104.542198] [DEBUG] name: ep8out, mp: 1024
[  104.548033] [DEBUG] name: ep9out, mp: 1024
[  104.552214] [DEBUG] name: ep10out, mp: 1024
[  104.558127] [DEBUG] name: ep11out, mp: 1024
[  104.562364] [DEBUG] name: ep12out, mp: 1024
[  104.568282] [DEBUG] name: ep13out, mp: 1024
[  104.572553] [DEBUG] name: ep14out, mp: 1024
[  104.578492] [DEBUG] name: ep15out, mp: 1024
[  104.583437] [DEBUG] name: ep1in, mp: 1024
[  104.587462] [DEBUG] name: ep2in, mp: 1024
[  104.591525] [DEBUG] uvc->video.ep->address=82
[  104.597864] [DEBUG] drivers/usb/gadget/composite.c : id 0 : 0
[  104.604371] [DEBUG] drivers/usb/gadget/composite.c : id 1 : 0
[  104.610141] [DEBUG] usb_interface_id0=0
[  104.615350] [DEBUG] drivers/usb/gadget/composite.c : id 0 : 1
[  104.621120] [DEBUG] drivers/usb/gadget/composite.c : id 1 : 1
[  104.628286] [DEBUG] usb_interface_id1=1
[  104.632138] [DEBUG] USB_SPEED_FULL=2
[  104.637070] [DEBUG] drivers/usb/gadget/function/f_uvc.c : size of
descriptor : 38
[  104.645314] [DEBUG] uvc_streaming_header->bEndpointAddress : 82
[  104.651258] [DEBUG] USB_SPEED_HIGH=3
[  104.656195] [DEBUG] drivers/usb/gadget/function/f_uvc.c : size of
descriptor : 38
[  104.664446] [DEBUG] uvc_streaming_header->bEndpointAddress : 82
[  104.670392] [DEBUG] v4l2_dev->name:
[  104.675324] [DEBUG] v4l2_dev->name: configfs-gadget gadget
[  104.680833] [DEBUG] dev->driver->name: configfs-gadget dev_name(dev): gadget
[  104.689243] [DEBUG] video-> fcc = 1448695129 bpp = 16 width = 320
height = 240 imagesize = 153600
[  104.698039] [DEBUG] queue.type = 2
[  104.701634] [DEBUG] drivers/usb/gadget/function/f_uvc.c : uvc_register_video
[  104.710668] [DEBUG] 

Re: [PATCH v17 2/3] usb: USB Type-C connector class

[Guenter Roeck]

On 03/07/2017 02:30 PM, Mats Karrman wrote:
[ ... ]



I'm still struggling to catch up on what you guys have been up to during the
last year or so :-) and came across some patches of Guenter from last October:

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1243527.html

What happened to them? Has there been any progress since then?



Updates to keep in sync with API changes, bug fixes, and minor improvements,
for the most part. I can post a current version if there is interest.
The latest version is also available from
https://chromium-review.googlesource.com/#/c/389917/

Guenter

--
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

Re: [PATCH v17 2/3] usb: USB Type-C connector class

[Guenter Roeck]

On 03/07/2017 12:57 AM, Heikki Krogerus wrote:

On Tue, Mar 07, 2017 at 01:36:29AM +, Peter Chen wrote:

On Mon, Mar 06, 2017 at 09:15:51AM +0800, Peter Chen wrote:

What interface you use when you receive this event to handle
dual-role switch? I am wonder if a common dual-role class is
needed, then we can have a common user utility.

Eg, if "data_role" has changed, the udev can echo "data_role" to
/sys/class/usb-dual-role/role


No. If the partner executes successfully for example DR_Swap
message, the kernel has to take care everything that is needed for
the role to be what ever was negotiated on its own. User space can't
be involved with that.



Would you give me an example how kernel handle this? How type-C event
triggers role switch?


On our boards, the firmware or EC (or ACPI) configures the hardware as needed
and also notifies the components using ACPI if needed. It's often not even 
possible to
directly configure the components/hardware for a particular role.



You mean type-C trigger an ACPI event, and this ACPI event can notify related
USB controller driver doing role switch?


No (firmware programs the dual-role hw/registers), but never mind.
That could be the case.


If it is correct, there is a notifier between type-C
and USB controller driver, how to define this notifier for non-ACPI platform?


Once there is a platform with Type-C like that, the problem needs to
be solved. However..


I'm not commenting on Roger's dual role patch series, but I don't really think 
it should
be mixed with Type-C. USB Type-C and USB Power Delivery define their own ways
of handling the roles, and they are not limited to the data role only. Things 
like OTG
for example will, and actually can not be supported. With Type-C we will have
competing state machines compared to OTG. The dual-role framework may be
useful on systems that provide more traditional connectors, which possibly have 
the
ID-pin like micro-AB, and possibly also support OTG. It can also be something 
that
exist in parallel with the Type-C class, but there just can not be any 
dependencies
between the two.



Yes, there are two independent things. But if the kernel doesn't have a 
notifier between
type-C message sender (type-c class) and message receiver (like USB controller 
driver
for role switch or other drivers for alternate mode message), we had to find 
some ways at
userspace.


..what ever the solution is, it really can't rely on user space.



... and, at least for our application, using extcon for the necessary 
notifications
works just fine.

Guenter

--
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

Re: [PATCH 1/2] usb: xhci-mtk: rebuild xhci_mtk_setup()

[Chunfeng Yun]

On Tue, 2017-03-07 at 16:57 +0200, Mathias Nyman wrote:
> On 07.03.2017 08:57, Chunfeng Yun wrote:
> > simplify xhci_mtk_setup() and add xhci_mtk_start() for
> > xhci_driver_overrides struct
> >
> 
> Code itself looks fine, but it's bit unclear for me what the benefit of this 
> is?
> 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >   drivers/usb/host/xhci-mtk.c |   16 +++-
> >   1 file changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > index 67d5dc7..9636884 100644
> > --- a/drivers/usb/host/xhci-mtk.c
> > +++ b/drivers/usb/host/xhci-mtk.c
> > @@ -381,8 +381,10 @@ static int usb_wakeup_of_property_parse(struct 
> > xhci_hcd_mtk *mtk,
> >   }
> >
> >   static int xhci_mtk_setup(struct usb_hcd *hcd);
> > +static int xhci_mtk_start(struct usb_hcd *hcd);
> >   static const struct xhci_driver_overrides xhci_mtk_overrides __initconst 
> > = {
> > .reset = xhci_mtk_setup,
> > +   .start = xhci_mtk_start,
> >   };
> >
> >   static struct hc_driver __read_mostly xhci_mtk_hc_driver;
> > @@ -492,7 +494,6 @@ static void xhci_mtk_quirks(struct device *dev, struct 
> > xhci_hcd *xhci)
> >   /* called during probe() after chip reset completes */
> >   static int xhci_mtk_setup(struct usb_hcd *hcd)
> >   {
> > -   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
> > int ret;
> >
> > @@ -502,9 +503,14 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
> > return ret;
> > }
> >
> > -   ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
> > -   if (ret)
> > -   return ret;
> > +   return xhci_gen_setup(hcd, xhci_mtk_quirks);
> > +}
> > +
> > +static int xhci_mtk_start(struct usb_hcd *hcd)
> > +{
> > +   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > +   struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
> > +   int ret;
> >
> > if (usb_hcd_is_primary_hcd(hcd)) {
> > mtk->num_u3_ports = xhci->num_usb3_ports;
> 
> In theory this causes xhci_mtk_sch_init() to allocate new memory
> for mtk->sch_array every time   .start callback is called.
> 
I agree with you, it indeed a problem no matter called in .reset
or .start in theory. Maybe it's better to call it in probe().

> In practice it should not matter as .start is only called
> when hcd is added in usb core.
> 
> Still wondering if there is a reason for this change?
Just make xhci_mtk_setup() look simple.
> 
> -Mathias
> 
> 


--
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

Re: [PATCH 1/2] usb: xhci-mtk: check hcc_params after adding primary hcd

[Chunfeng Yun]

On Tue, 2017-03-07 at 17:10 +0200, Mathias Nyman wrote:
> On 07.03.2017 05:32, Chunfeng Yun wrote:
> > hcc_params is set in xhci_gen_setup() called from usb_add_hcd(),
> > so checks the Maximum Primary Stream Array Size in the hcc_params
> > register after adding primary hcd.
> >
> > Signed-off-by: Chunfeng Yun 
> > ---
> >   drivers/usb/host/xhci-mtk.c |6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > index 9066ec9..6ac73a6 100644
> > --- a/drivers/usb/host/xhci-mtk.c
> > +++ b/drivers/usb/host/xhci-mtk.c
> > @@ -678,13 +678,13 @@ static int xhci_mtk_probe(struct platform_device 
> > *pdev)
> > goto power_off_phys;
> > }
> >
> > -   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
> > -   xhci->shared_hcd->can_do_streams = 1;
> > -
> > ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
> > if (ret)
> > goto put_usb3_hcd;
> >
> > +   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
> > +   xhci->shared_hcd->can_do_streams = 1;
> > +
> > ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
> > if (ret)
> > goto dealloc_usb2_hcd;
> >
> 
> Thanks.
> Looks like streams check has never worked for Mediatek xHC hosts,
> 
> Do you know if this has caused any issues?
> looks like it should go usb-linus and maybe stable kernels as well.
No issues on mt8173, because it doesn't support bulk stream. But it
causes a issue on the newest SoC which is not upstreamed, so I think it
needn't go stable kernels.

Thank you.
>   
> -Mathias


--
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

Re: [PATCH v17 2/3] usb: USB Type-C connector class

[Mats Karrman]

On 2017-03-06 14:14, Heikki Krogerus wrote:


Hi Mats,

On Fri, Mar 03, 2017 at 08:27:08PM +0100, Mats Karrman wrote:

My system is a bit different. It's an i.MX6 SoC with the typec phy and DP 
controller connected
directly to the SoC and it's using DTB/OF.

Is this "DP controller" a controller that is capable of taking care of
the USB Power Delivery communication with the partner regarding
DisplayPort alternate mode?

No, the "DP controller" just talks DP and knows nothing about Type-C or USB PD.
It takes a video stream from the SoC and turns it into a DP link, set up and 
orchestrated
by the corresponding driver. And all the driver needs from Type-C is the 
plugged in / interrupt /
plugged out events.

Got it.


The analog switching between USB / safe / DP signal levels in the Type-C 
connector is, I think,
best handled by the software doing the USB PD negotiation / Altmode handling 
(using some GPIOs).


Do we need to further standardize attributes under (each) specific alternate 
mode to
include things such as HPD for the DP mode?

I'm not completely sure what kind of system you have, but I would
imagine that if we had the bus, your DP controller driver would be the
port (and partner) alternate mode driver. The bus would bind you to
the typec phy.

So, both the DP controller and the USB PD phy are I2C devices, and now I have 
to make them both
attach to the AM bus as well?

The DP controller would provide the driver and the USB PD phy
(actually, the typec class) the device.

Would it be a problem to register these I2C devices with some other
subsystem, was it extcon or something like AM bus? It really would not
be that uncommon. Or have I misunderstood your question?


OK, so a bus could be used for drivers to find each other but it still does not 
say
anything about how those drivers are supposed to communicate so that must be 
prescribed
separately, right?

If I read Heikki's original suggestion I understand it like the DP driver would 
be
responsible for AM specific USB PD/VDM communication. But wouldn't that lead
to a lot of code duplication since the AM protocol is the same for all drivers 
of
a kind?

I'm still struggling to catch up on what you guys have been up to during the
last year or so :-) and came across some patches of Guenter from last October:

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1243527.html

What happened to them? Has there been any progress since then?

BR // Mats

--
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

Re: bug? dwc2: insufficient fifo memory

[John Youn]

+linux-usb

On 2/24/2017 2:46 PM, John Stultz wrote:
> Hey John,
>   So after the USB tree landed in 4.11-rc, I've been seeing the
> following warning at bootup.
>
> It seems the fifo_mem/total_fifo_size value on hikey is 1920, but I'm
> seeing the addresses zip upward quickly as the txfsz values are all
> 2048.  Not exactly sure whats wrong here.  Things still seem to work
> properly.
>

Hi John,

Could you send us a register dump before and after you load the
function? You can get this through debugfs.

Regards,
John
--
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

Re: [PATCH 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t

[Shaohua Li]

On Mon, Mar 06, 2017 at 04:20:57PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
>  drivers/md/raid5-cache.c |  8 +++---
>  drivers/md/raid5.c   | 66 
> 
>  drivers/md/raid5.h   |  3 ++-
>  3 files changed, 39 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> index 3f307be..6c05e12 100644
> --- a/drivers/md/raid5-cache.c
> +++ b/drivers/md/raid5-cache.c

snip
>  sh->check_state, sh->reconstruct_state);
>  
>   analyse_stripe(sh, );
> @@ -4924,7 +4924,7 @@ static void activate_bit_delay(struct r5conf *conf,
>   struct stripe_head *sh = list_entry(head.next, struct 
> stripe_head, lru);
>   int hash;
>   list_del_init(>lru);
> - atomic_inc(>count);
> + refcount_inc(>count);
>   hash = sh->hash_lock_index;
>   __release_stripe(conf, sh, _inactive_list[hash]);
>   }
> @@ -5240,7 +5240,7 @@ static struct stripe_head *__get_priority_stripe(struct 
> r5conf *conf, int group)
>   sh->group = NULL;
>   }
>   list_del_init(>lru);
> - BUG_ON(atomic_inc_return(>count) != 1);
> + BUG_ON(refcount_inc_not_zero(>count));

This changes the behavior. refcount_inc_not_zero doesn't inc if original value 
is 0

Thanks,
Shaohua
--
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

Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

[Shaohua Li]

On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.

Looks good. Let me know how do you want to route the patch to upstream.
 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
>  drivers/md/md.c | 6 +++---
>  drivers/md/md.h | 3 ++-
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 985374f..94c8ebf 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -449,7 +449,7 @@ EXPORT_SYMBOL(md_unplug);
>  
>  static inline struct mddev *mddev_get(struct mddev *mddev)
>  {
> - atomic_inc(>active);
> + refcount_inc(>active);
>   return mddev;
>  }
>  
> @@ -459,7 +459,7 @@ static void mddev_put(struct mddev *mddev)
>  {
>   struct bio_set *bs = NULL;
>  
> - if (!atomic_dec_and_lock(>active, _mddevs_lock))
> + if (!refcount_dec_and_lock(>active, _mddevs_lock))
>   return;
>   if (!mddev->raid_disks && list_empty(>disks) &&
>   mddev->ctime == 0 && !mddev->hold_active) {
> @@ -495,7 +495,7 @@ void mddev_init(struct mddev *mddev)
>   INIT_LIST_HEAD(>all_mddevs);
>   setup_timer(>safemode_timer, md_safemode_timeout,
>   (unsigned long) mddev);
> - atomic_set(>active, 1);
> + refcount_set(>active, 1);
>   atomic_set(>openers, 0);
>   atomic_set(>active_io, 0);
>   spin_lock_init(>lock);
> diff --git a/drivers/md/md.h b/drivers/md/md.h
> index b8859cb..4811663 100644
> --- a/drivers/md/md.h
> +++ b/drivers/md/md.h
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -360,7 +361,7 @@ struct mddev {
>*/
>   struct mutexopen_mutex;
>   struct mutexreconfig_mutex;
> - atomic_tactive; /* general refcount */
> + refcount_t  active; /* general refcount */
>   atomic_topeners;/* number of active 
> opens */
>  
>   int changed;/* True if we might 
> need to
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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

[PATCH 0/2] USB: iowarrior: fix missing endpoint sanity checks

[Johan Hovold]

These patches add the missing endpoint sanity checks to probe that are
needed to prevent a couple of NULL-derefs which could be trigger by a
malicious device.

Johan


Johan Hovold (2):
  USB: iowarrior: fix NULL-deref at probe
  USB: iowarrior: fix NULL-deref in write

 drivers/usb/misc/iowarrior.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

-- 
2.12.0

--
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

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Alan Stern]

On Tue, 7 Mar 2017, Ajay Kaher wrote:

> > On Fri, 3 Mar 2017, Ajay Kaher wrote:
> > 
> > > > usb_class->kref is not accessible outside the file.c
> > > > as usb_class is _static_ inside the file.c and
> > > > pointer of usb_class->kref is not passed anywhere.
> > > > 
> > > > Hence as you wanted, there are no references of usb_class->kref
> > > > other than taken by init_usb_class() and released by 
> > >destroy_usb_class().
> > > 
> > > Verified the code again, I hope my last comments clarifed the things
> > > which came in your mind and helps you to accept the patch :)
> >  
> > Your main point is that usb_class->kref is accessed from only two
> > points, both of which are protected by the new mutex.  This means there
> > is no reason for the value to be a struct kref at all.  You should
> > change it to an int (and change its name).  Leaving it as a kref will
> > make readers wonder why it needs to be updated atomically.
> 
> At many places in Linux kernel, instances of Kref have been used within
> Mutex, SpinLock and don’t have any side effect.
> 
> Making to int and handle (i.e. get/put) it within file.c seems
> not good as we have Kref. Instead, we can have non_atomic version of kref.
> We can discuss about non_atomic kref in another thread, if you are interested.

Okay.

> > Also, why does destroy_usb_class() have that "if (usb_class) "test? 
> > Isn't it true that usb_class can never be NULL there?
> 
> Removed in Patch v4.
> 
> thanks,
> ajay kaher
>  
>   
> Signed-off-by: Ajay Kaher
>  
> ---
> 
>  drivers/usb/core/file.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
> index 822ced9..422ce7b 100644
> --- a/drivers/usb/core/file.c
> +++ b/drivers/usb/core/file.c
> @@ -27,6 +27,7 @@
>  #define MAX_USB_MINORS 256
>  static const struct file_operations *usb_minors[MAX_USB_MINORS];
>  static DECLARE_RWSEM(minor_rwsem);
> +static DEFINE_MUTEX(init_usb_class_mutex);
> 
>  static int usb_open(struct inode *inode, struct file *file)
>  {
> @@ -109,8 +110,9 @@ static void release_usb_class(struct kref *kref)
> 
>  static void destroy_usb_class(void)
>  {
> -   if (usb_class)
> -   kref_put(_class->kref, release_usb_class);
> +   mutex_lock(_usb_class_mutex);
> +   kref_put(_class->kref, release_usb_class);
> +   mutex_unlock(_usb_class_mutex);
>  }
> 
>  int usb_major_init(void)
> @@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
> if (intf->minor >= 0)
> return -EADDRINUSE;
> 
> +   mutex_lock(_usb_class_mutex);
> retval = init_usb_class();
> +   mutex_unlock(_usb_class_mutex);
> +
> if (retval)
> return retval;

Acked-by: Alan Stern 

Alan Stern

--
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

[PATCH] [media] mceusb: fix NULL-deref at probe

[Johan Hovold]

Make sure to check for the required out endpoint to avoid dereferencing
a NULL-pointer in mce_request_packet should a malicious device lack such
an endpoint. Note that this path it hit during probe.

Fixes: 66e89522aff7 ("V4L/DVB: IR: add mceusb IR receiver driver")
Cc: stable  # 2.6.36
Signed-off-by: Johan Hovold 
---

Found through inspection, compile tested only.

Johan


 drivers/media/rc/mceusb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 238d8eaf7d94..93b16fe3ab38 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -1288,8 +1288,8 @@ static int mceusb_dev_probe(struct usb_interface *intf,
}
}
}
-   if (ep_in == NULL) {
-   dev_dbg(>dev, "inbound and/or endpoint not found");
+   if (!ep_in || !ep_out) {
+   dev_dbg(>dev, "required endpoints not found\n");
return -ENODEV;
}
 
-- 
2.12.0

--
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

Implementing MSI support on my platform

[Mason]

Hello,

As suggested by Marc, I'm trying to adapt
  drivers/pci/host/pcie-altera-msi.c
to my platform.


Here are my changes to the existing driver:

diff --git a/drivers/pci/host/pcie-altera-msi.c 
b/drivers/pci/host/pcie-altera-msi.c
index 4e5d628e8cd4..914cd26b2a53 100644
--- a/drivers/pci/host/pcie-altera-msi.c
+++ b/drivers/pci/host/pcie-altera-msi.c
@@ -18,6 +18,7 @@
  * this program.  If not, see .
  */
 
+#define DEBUG 42
 #include 
 #include 
 #include 
@@ -31,7 +32,11 @@
 
 #define MSI_STATUS 0x0
 #define MSI_ERROR  0x4
+#if 0
 #define MSI_INTMASK0x8
+#else
+#define MSI_INTMASK0x20
+#endif
 
 #define MAX_MSI_VECTORS32
 
@@ -51,12 +56,19 @@ struct altera_msi {
 static inline void msi_writel(struct altera_msi *msi, const u32 value,
  const u32 reg)
 {
+   printk("%s: reg=%u val=0x%x\n", __func__, reg, value);
writel_relaxed(value, msi->csr_base + reg);
 }
 
 static inline u32 msi_readl(struct altera_msi *msi, const u32 reg)
 {
+#if 0
return readl_relaxed(msi->csr_base + reg);
+#else
+   u32 val = readl_relaxed(msi->csr_base + reg);
+   printk("%s: reg=%u val=0x%x\n", __func__, reg, val);
+   return val;
+#endif
 }
 
 static void altera_msi_isr(struct irq_desc *desc)
@@ -68,14 +80,19 @@ static void altera_msi_isr(struct irq_desc *desc)
u32 bit;
u32 virq;
 
+   printk("%s: ENTER\n", __func__);
chained_irq_enter(chip, desc);
msi = irq_desc_get_handler_data(desc);
num_of_vectors = msi->num_of_vectors;
 
while ((status = msi_readl(msi, MSI_STATUS)) != 0) {
for_each_set_bit(bit, , msi->num_of_vectors) {
+#if 0
/* Dummy read from vector to clear the interrupt */
readl_relaxed(msi->vector_base + (bit * sizeof(u32)));
+#else
+   msi_writel(msi, bit, MSI_STATUS);
+#endif
 
virq = irq_find_mapping(msi->inner_domain, bit);
if (virq)
@@ -103,7 +120,11 @@ static void altera_msi_isr(struct irq_desc *desc)
 static void altera_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
 {
struct altera_msi *msi = irq_data_get_irq_chip_data(data);
+#if 0
phys_addr_t addr = msi->vector_phy + (data->hwirq * sizeof(u32));
+#else
+   phys_addr_t addr = 0x800 + 0x2e07c;
+#endif
 
msg->address_lo = lower_32_bits(addr);
msg->address_hi = upper_32_bits(addr);
@@ -247,6 +268,7 @@ static int altera_msi_probe(struct platform_device *pdev)
return PTR_ERR(msi->csr_base);
}
 
+#if 0
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
   "vector_slave");
msi->vector_base = devm_ioremap_resource(>dev, res);
@@ -256,6 +278,10 @@ static int altera_msi_probe(struct platform_device *pdev)
}
 
msi->vector_phy = res->start;
+#else
+   msi->vector_base = (void *)0xdeedbeef;
+   msi->vector_phy = 0xdeadbeef;
+#endif
 
if (of_property_read_u32(np, "num-vectors", >num_of_vectors)) {
dev_err(>dev, "failed to parse the number of vectors\n");
@@ -276,6 +302,8 @@ static int altera_msi_probe(struct platform_device *pdev)
irq_set_chained_handler_and_data(msi->irq, altera_msi_isr, msi);
platform_set_drvdata(pdev, msi);
 
+   printk("%s: res=%pr irq=%d ret=%d\n", __func__, res, msi->irq, ret);
+
return 0;
 
 err:



Here are the relevant DT nodes:

msi0: msi@2e080 {
compatible = "altr,msi-1.0";
reg = <0x2e080 0x40>;
reg-names = "csr";
interrupt-parent = <>;
interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
msi-controller;
num-vectors = <32>;
};

pcie@5000 {
compatible = "sigma,smp8759-pcie";
reg = <0x5000 0x800>;
device_type = "pci";
bus-range = <0x0 0x7f>;
#size-cells = <2>;
#address-cells = <3>;
#interrupt-cells = <1>;
/* BUS_ADDRESS(3)  CPU_PHYSICAL(1)  SIZE(2) */
ranges = <0x0200 0x0 0x800  0x5800  0x0 
0x800>;
msi-parent = <>;
};



Here are the relevant boot-time logs I see:

[0.392199] altera_msi_probe: res=[mem 0x0002e080-0x0002e0bf flags 0x200] 
irq=22 ret=0
...
[0.993868] OF: PCI: host bridge /soc/pcie@5000 ranges:
[0.999582] OF: PCI: Parsing ranges property...
[1.004250] OF: PCI:   MEM 0x5800..0x5fff -> 0x0800
[1.011770] pci_tango 5000.pcie: ECAM at [mem 0x5000-0x57ff] for 

Re: [PATCH 1/2] usb: xhci-mtk: check hcc_params after adding primary hcd

[Mathias Nyman]

On 07.03.2017 05:32, Chunfeng Yun wrote:

hcc_params is set in xhci_gen_setup() called from usb_add_hcd(),
so checks the Maximum Primary Stream Array Size in the hcc_params
register after adding primary hcd.

Signed-off-by: Chunfeng Yun 
---
  drivers/usb/host/xhci-mtk.c |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 9066ec9..6ac73a6 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -678,13 +678,13 @@ static int xhci_mtk_probe(struct platform_device *pdev)
goto power_off_phys;
}

-   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
-   xhci->shared_hcd->can_do_streams = 1;
-
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;

+   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
+   xhci->shared_hcd->can_do_streams = 1;
+
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
goto dealloc_usb2_hcd;



Thanks.
Looks like streams check has never worked for Mediatek xHC hosts,

Do you know if this has caused any issues?
looks like it should go usb-linus and maybe stable kernels as well.
 
-Mathias

--
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

Re: [PATCH 1/1] usb: host: xhci-dbg: HCIVERSION should be a binary number

[Mathias Nyman]

On 07.03.2017 05:04, Peter Chen wrote:

According to xHCI spec, HCIVERSION containing a BCD encoding
of the xHCI specification revision number, 0100h corresponds
to xHCI version 1.0. Change "100" as "0x100".

Cc: Lu Baolu 
Cc: stable 
Fixes: 04abb6de2825 ("xhci: Read and parse new xhci
1.1 capability register")
Signed-off-by: Peter Chen 
---
  drivers/usb/host/xhci-dbg.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 363d125..2b4a00f 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -109,7 +109,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci, "RTSOFF 0x%x:\n", temp & RTSOFF_MASK);

/* xhci 1.1 controllers have the HCCPARAMS2 register */
-   if (hci_version > 100) {
+   if (hci_version > 0x100) {
temp = readl(>cap_regs->hcc_params2);
xhci_dbg(xhci, "HCC PARAMS2 0x%x:\n", (unsigned int) temp);
xhci_dbg(xhci, "  HC %s Force save context capability",



Thanks, queuing this

-Mathias
  


--
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

[PATCH 1/2] USB: iowarrior: fix NULL-deref at probe

[Johan Hovold]

Make sure to check for the required interrupt-in endpoint to avoid
dereferencing a NULL-pointer should a malicious device lack such an
endpoint.

Note that a fairly recent change purported to fix this issue, but added
an insufficient test on the number of endpoints only, a test which can
now be removed.

Fixes: 4ec0ef3a8212 ("USB: iowarrior: fix oops with malicious USB
descriptors")
Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
Cc: stable  # 2.6.21
Signed-off-by: Johan Hovold 
---
 drivers/usb/misc/iowarrior.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c
index 095778ff984d..3ad058cbe6ca 100644
--- a/drivers/usb/misc/iowarrior.c
+++ b/drivers/usb/misc/iowarrior.c
@@ -781,12 +781,6 @@ static int iowarrior_probe(struct usb_interface *interface,
iface_desc = interface->cur_altsetting;
dev->product_id = le16_to_cpu(udev->descriptor.idProduct);
 
-   if (iface_desc->desc.bNumEndpoints < 1) {
-   dev_err(>dev, "Invalid number of endpoints\n");
-   retval = -EINVAL;
-   goto error;
-   }
-
/* set up the endpoint information */
for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
endpoint = _desc->endpoint[i].desc;
@@ -797,6 +791,13 @@ static int iowarrior_probe(struct usb_interface *interface,
/* this one will match for the IOWarrior56 only */
dev->int_out_endpoint = endpoint;
}
+
+   if (!dev->int_in_endpoint) {
+   dev_err(>dev, "no interrupt-in endpoint found\n");
+   retval = -ENODEV;
+   goto error;
+   }
+
/* we have to check the report_size often, so remember it in the 
endianness suitable for our machine */
dev->report_size = usb_endpoint_maxp(dev->int_in_endpoint);
if ((dev->interface->cur_altsetting->desc.bInterfaceNumber == 0) &&
-- 
2.12.0

--
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

Re: [PATCH 2/2] usb: xhci: remove dummy extra_priv_size for size of xhci_hcd struct

[Mathias Nyman]

On 07.03.2017 13:02, Thierry Reding wrote:

On Tue, Mar 07, 2017 at 11:32:23AM +0800, Chunfeng Yun wrote:

because hcd_priv_size is already size of xhci_hcd struct,
extra_priv_size is not needed anymore for MTK and tegra drivers.

Signed-off-by: Chunfeng Yun 
---
  drivers/usb/host/xhci-mtk.c   |1 -
  drivers/usb/host/xhci-tegra.c |1 -
  2 files changed, 2 deletions(-)




Nice catch, thanks.
queued.


For Tegra:

Tested-by: Thierry Reding 
Acked-by: Thierry Reding 



adding tags

-Mathias

--
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

[PATCH 2/2] USB: iowarrior: fix NULL-deref in write

[Johan Hovold]

Make sure to verify that we have the required interrupt-out endpoint for
IOWarrior56 devices to avoid dereferencing a NULL-pointer in write
should a malicious device lack such an endpoint.

Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
Cc: stable  # 2.6.21
Signed-off-by: Johan Hovold 
---
 drivers/usb/misc/iowarrior.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c
index 3ad058cbe6ca..37c63cb39714 100644
--- a/drivers/usb/misc/iowarrior.c
+++ b/drivers/usb/misc/iowarrior.c
@@ -798,6 +798,14 @@ static int iowarrior_probe(struct usb_interface *interface,
goto error;
}
 
+   if (dev->product_id == USB_DEVICE_ID_CODEMERCS_IOW56) {
+   if (!dev->int_out_endpoint) {
+   dev_err(>dev, "no interrupt-out endpoint 
found\n");
+   retval = -ENODEV;
+   goto error;
+   }
+   }
+
/* we have to check the report_size often, so remember it in the 
endianness suitable for our machine */
dev->report_size = usb_endpoint_maxp(dev->int_in_endpoint);
if ((dev->interface->cur_altsetting->desc.bInterfaceNumber == 0) &&
-- 
2.12.0

--
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

Re: [PATCH 1/2] usb: xhci-mtk: rebuild xhci_mtk_setup()

[Mathias Nyman]

On 07.03.2017 08:57, Chunfeng Yun wrote:

simplify xhci_mtk_setup() and add xhci_mtk_start() for
xhci_driver_overrides struct



Code itself looks fine, but it's bit unclear for me what the benefit of this is?


Signed-off-by: Chunfeng Yun 
---
  drivers/usb/host/xhci-mtk.c |   16 +++-
  1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 67d5dc7..9636884 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -381,8 +381,10 @@ static int usb_wakeup_of_property_parse(struct 
xhci_hcd_mtk *mtk,
  }

  static int xhci_mtk_setup(struct usb_hcd *hcd);
+static int xhci_mtk_start(struct usb_hcd *hcd);
  static const struct xhci_driver_overrides xhci_mtk_overrides __initconst = {
.reset = xhci_mtk_setup,
+   .start = xhci_mtk_start,
  };

  static struct hc_driver __read_mostly xhci_mtk_hc_driver;
@@ -492,7 +494,6 @@ static void xhci_mtk_quirks(struct device *dev, struct 
xhci_hcd *xhci)
  /* called during probe() after chip reset completes */
  static int xhci_mtk_setup(struct usb_hcd *hcd)
  {
-   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
int ret;

@@ -502,9 +503,14 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
return ret;
}

-   ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
-   if (ret)
-   return ret;
+   return xhci_gen_setup(hcd, xhci_mtk_quirks);
+}
+
+static int xhci_mtk_start(struct usb_hcd *hcd)
+{
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+   struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
+   int ret;

if (usb_hcd_is_primary_hcd(hcd)) {
mtk->num_u3_ports = xhci->num_usb3_ports;


In theory this causes xhci_mtk_sch_init() to allocate new memory
for mtk->sch_array every time   .start callback is called.

In practice it should not matter as .start is only called
when hcd is added in usb core.

Still wondering if there is a reason for this change?

-Mathias


--
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

RE: [PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t

[Reshetova, Elena]

> Hi Elena,
> 
> On Mon, Mar 06, 2017 at 04:21:00PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> >  drivers/media/v4l2-core/videobuf2-memops.c | 6 +++---
> >  include/media/videobuf2-memops.h   | 3 ++-
> >  2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/videobuf2-memops.c 
> > b/drivers/media/v4l2-
> core/videobuf2-memops.c
> > index 1cd322e..4bb8424 100644
> > --- a/drivers/media/v4l2-core/videobuf2-memops.c
> > +++ b/drivers/media/v4l2-core/videobuf2-memops.c
> > @@ -96,10 +96,10 @@ static void vb2_common_vm_open(struct
> vm_area_struct *vma)
> > struct vb2_vmarea_handler *h = vma->vm_private_data;
> >
> > pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> > -  __func__, h, atomic_read(h->refcount), vma->vm_start,
> > +  __func__, h, refcount_read(h->refcount), vma->vm_start,
> >vma->vm_end);
> >
> > -   atomic_inc(h->refcount);
> > +   refcount_inc(h->refcount);
> >  }
> >
> >  /**
> > @@ -114,7 +114,7 @@ static void vb2_common_vm_close(struct
> vm_area_struct *vma)
> > struct vb2_vmarea_handler *h = vma->vm_private_data;
> >
> > pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> > -  __func__, h, atomic_read(h->refcount), vma->vm_start,
> > +  __func__, h, refcount_read(h->refcount), vma->vm_start,
> >vma->vm_end);
> >
> > h->put(h->arg);
> > diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-
> memops.h
> > index 36565c7a..a6ed091 100644
> > --- a/include/media/videobuf2-memops.h
> > +++ b/include/media/videobuf2-memops.h
> > @@ -16,6 +16,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  /**
> >   * struct vb2_vmarea_handler - common vma refcount tracking handler
> > @@ -25,7 +26,7 @@
> >   * @arg:   argument for @put callback
> >   */
> >  struct vb2_vmarea_handler {
> > -   atomic_t*refcount;
> > +   refcount_t  *refcount;
> 
> This is a pointer to refcount, not refcount itself. The refcount is part of
> a memory type specific struct, the types that you change in the following
> three patches. I guess it would still compile and work as separate patches
> but you'd sure get warnings at least.

Actually it doesn't compile without this patch if I remember it correctly back 
in past when I was initially splitting the patches per variable. 

> 
> How about merging this and the three following patches that change the memop
> refcount types?

Sounds good!

Best Regards,
Elena.
> 
> > void(*put)(void *arg);
> > void*arg;
> >  };
> 
> --
> Kind regards,
> 
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi   XMPP: sai...@retiisi.org.uk
--
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

RE: [PATCH 12/29] drivers, media: convert s2255_dev.num_channels from atomic_t to refcount_t

[Reshetova, Elena]

> Hi Elena,
> 
> On Mon, Mar 06, 2017 at 04:20:59PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> ...
> > @@ -1688,7 +1689,7 @@ static int s2255_probe_v4l(struct s2255_dev *dev)
> > "failed to register
> video device!\n");
> > break;
> > }
> > -   atomic_inc(>num_channels);
> > +   refcount_set(>num_channels, 1);
> 
> That's not right. The loop runs four iterations and the value after the
> loop should be indeed the number of channels.

Oh, yes, I was blind here, sorry. The problem why it cannot be left as inc is 
because it would do increment from zero here, which is not allowed by 
refcount_t interface. 

> atomic_t isn't really used for reference counting here, but storing out how
> many "channels" there are per hardware device, with maximum number of four
> (4). I'd leave this driver using atomic_t.
Yes, sounds like the best thing to do. I will drop this patch. 

Thank you for reviews!

Best Regards,
Elena.
> 
> > v4l2_info(>v4l2_dev, "V4L2 device registered
> as %s\n",
> >   video_device_node_name(
> >vdev));
> >
> 
> --
> Kind regards,
> 
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi   XMPP: sai...@retiisi.org.uk
--
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

Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour

[Felipe Balbi]

Hi,

Laurent Pinchart  writes:
> Hi Felipe,
>
> On Tuesday 07 Mar 2017 12:57:40 Felipe Balbi wrote:
>> Laurent Pinchart writes:
>> > On Friday 03 Mar 2017 13:17:15 Roger Quadros wrote:
>> >> On alternate setting change, webcam gadget sends us a UVC_EVENT_STREAMON
>> >> or UVC_EVENT_STREAMOFF event. It expects delayed status response on
>> >> STREAMON event only but doesn't expect us to send that response over USB.
>> >> It sends the delayed response when we issue the VIDIOC_STREAMON ioctl.
>> >> 
>> >> So we must not send UVCIOC_SEND_RESPONSE ioctl in these cases that too
>> >> with invalid response length.
>> > 
>> > The commit message only explains why we should not call
>> > UVCIOC_SEND_RESPONSE in response to a STREAMON event, but not why we
>> > shouldn't either in response to a STREAMOFF event. The patch is correct
>> > changing both, but I propose wording the above two paragraphs as follows.
>> > 
>> > "uvc-gadget: Do not send Set Interface (alternate setting) response twice
>> > 
>> > On alternate setting change, the webcam gadget sends us a
>> > UVC_EVENT_STREAMON or UVC_EVENT_STREAMOFF event. In the first case, the
>> > driver will issue a delayed status response automatically when we call
>> > the VIDIOC_STREAMON ioctl. In the second case, the driver sends the
>> > status response immediately. We must thus not send the status response
>> > manually with UVCIOC_SEND_RESPONSE in any of those cases."
>> > 
>> > If you're fine with that I'll change the message when applying, there's no
>> > need to resend the patch.
>> 
>> I have this in my testing/fixes and was planning to send it to Greg this
>> week. I can drop it from my queue, no problem, but then let me know as
>> you would need my acked-by.
>
> This is a userspace application patch. Feel free to send it to Greg, but I 
> don't think he will know what to do with it :-) Were you maybe confusing this 
> patch with the kernel fix that Roger sent a few days ago ? That one should be 
> queued, please keep it in your tree.

heh, my bad I got confused. I thought I was revieweing the kernel patch :-p

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour

[Laurent Pinchart]

Hi Felipe,

On Tuesday 07 Mar 2017 12:57:40 Felipe Balbi wrote:
> Laurent Pinchart writes:
> > On Friday 03 Mar 2017 13:17:15 Roger Quadros wrote:
> >> On alternate setting change, webcam gadget sends us a UVC_EVENT_STREAMON
> >> or UVC_EVENT_STREAMOFF event. It expects delayed status response on
> >> STREAMON event only but doesn't expect us to send that response over USB.
> >> It sends the delayed response when we issue the VIDIOC_STREAMON ioctl.
> >> 
> >> So we must not send UVCIOC_SEND_RESPONSE ioctl in these cases that too
> >> with invalid response length.
> > 
> > The commit message only explains why we should not call
> > UVCIOC_SEND_RESPONSE in response to a STREAMON event, but not why we
> > shouldn't either in response to a STREAMOFF event. The patch is correct
> > changing both, but I propose wording the above two paragraphs as follows.
> > 
> > "uvc-gadget: Do not send Set Interface (alternate setting) response twice
> > 
> > On alternate setting change, the webcam gadget sends us a
> > UVC_EVENT_STREAMON or UVC_EVENT_STREAMOFF event. In the first case, the
> > driver will issue a delayed status response automatically when we call
> > the VIDIOC_STREAMON ioctl. In the second case, the driver sends the
> > status response immediately. We must thus not send the status response
> > manually with UVCIOC_SEND_RESPONSE in any of those cases."
> > 
> > If you're fine with that I'll change the message when applying, there's no
> > need to resend the patch.
> 
> I have this in my testing/fixes and was planning to send it to Greg this
> week. I can drop it from my queue, no problem, but then let me know as
> you would need my acked-by.

This is a userspace application patch. Feel free to send it to Greg, but I 
don't think he will know what to do with it :-) Were you maybe confusing this 
patch with the kernel fix that Roger sent a few days ago ? That one should be 
queued, please keep it in your tree.

-- 
Regards,

Laurent Pinchart

--
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

Re: Question: Does usbip support USB 3.0?

[Yuyang Du]

Hi,

On Mon, Mar 06, 2017 at 10:19:39AM +0100, Krzysztof Opasiak wrote:
> >I did the experiment. Our device "requires" that the SUPER_SPPED be used.
> >So, we are attempting to add SUPER_SPEED support to usbip. To assess the
> >effort, could you please give us some pointers on how to do it? And what
> >are the difficulties?
> 
> In the beginning I would start with this commit:
> 
> 1cd8fd2887e162ad3d067150962cc3d32dcf3150
> 
> This commit adds Super Speed support to dummy_hcd so from the kernel
> point of view this should be a good source of knowledge how to add
> Super Speed mode to existing HCD.
 
Thanks a lot. I'll take a look at it.

> There is also other side, the protocol. Probably we won't be able to
> handle this using exiting protocol messages. At first glance I see
> at least one reason:
> 
> Documentation/usb/usbip_protocol.txt:
> 
> USBIP_RET_SUBMIT: Reply for submitting an URB
> 
>  Offset| Length | Value  | Description
> ---+++---
>  0 | 4  | 0x0003 | command
> ---+++---
>  4 | 4  || seqnum: URB sequence number
> ---+++---
>  8 | 4  || devid
> ---+++---
>  0xC   | 4  || direction: 0: USBIP_DIR_OUT
>|||1: USBIP_DIR_IN
> ---+++---
>  0x10  | 4  || ep: endpoint number
> ---+++---
>  0x14  | 4  || status: zero for successful URB
> transaction,
>|||   otherwise some kind of error happened.
> ---+++---
>  0x18  | 4  | n  | actual_length: number of URB data bytes
> ---+++---
>  0x1C  | 4  || start_frame: for an ISO frame the
> actually
>|||   selected frame for transmit.
> ---+++---
>  0x20  | 4  || number_of_packets
> ---+++---
>  0x24  | 4  || error_count
> ---+++---
>  0x28  | 8  || setup: data bytes for USB setup,
> filled with
>|||   zeros if not used
> ---+++---
>  0x30  | n  || URB data bytes. For ISO transfers
> the padding
>|||   between each ISO packets is not
> transmitted.
> 
> 
> 
> As you see we have a field for devid, direction and ep but we don't
> have a field for stream id.

Then, as Oliver pointed out, if we don't need bulk streams transfer type, the
current protocol should work fine, right?

Thanks,
Yuyang
--
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

Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour

[Felipe Balbi]

Hi,

Laurent Pinchart  writes:
> Hi Roger,
>
> Thank you for the patch.
>
> On Friday 03 Mar 2017 13:17:15 Roger Quadros wrote:
>> On alternate setting change, webcam gadget sends us a UVC_EVENT_STREAMON
>> or UVC_EVENT_STREAMOFF event. It expects delayed status response on
>> STREAMON event only but doesn't expect us to send that response over USB.
>> It sends the delayed response when we issue the VIDIOC_STREAMON ioctl.
>>
>> So we must not send UVCIOC_SEND_RESPONSE ioctl in these cases that too
>> with invalid response length.
>
> The commit message only explains why we should not call UVCIOC_SEND_RESPONSE 
> in response to a STREAMON event, but not why we shouldn't either in response 
> to a STREAMOFF event. The patch is correct changing both, but I propose 
> wording the above two paragraphs as follows.
>
> "uvc-gadget: Do not send Set Interface (alternate setting) response twice
>
> On alternate setting change, the webcam gadget sends us a UVC_EVENT_STREAMON 
> or UVC_EVENT_STREAMOFF event. In the first case, the driver will issue a 
> delayed status response automatically when we call the VIDIOC_STREAMON ioctl. 
> In the second case, the driver sends the status response immediately. We must 
> thus not send the status response manually with UVCIOC_SEND_RESPONSE in any 
> of 
> those cases."
>
> If you're fine with that I'll change the message when applying, there's no 
> need to resend the patch.

I have this in my testing/fixes and was planning to send it to Greg this
week. I can drop it from my queue, no problem, but then let me know as
you would need my acked-by.

-- 
balbi


signature.asc
Description: PGP signature

Re: query on UCSI

[Heikki Krogerus]

Hi,

On Tue, Mar 07, 2017 at 12:39:39AM +0530, Shah, Nehal-bakulchandra wrote:
> Hi Heikki ,
> 
> 
> Thanks for the prompt reply.
> If i understood correctly the current driver(drivers/usb/misc/ucsi.c) supports
> the OPM and rest all is taken care by EC FW  with BIOS .
> In ucsi.c file i did not find any mailbox related code. Am I missing something
> here?

The driver maps the region for the mailbox on line 478.

OPM needs to be able to access to the mailbox as normal Memory
resource. The UCSI BIOS implementation guide, in the example for the
requirements, only shows the OperationRegion, but that is not enough
of course as OperationRegions provides access to some data for other
ACPI methods, not for the OS.

Here's ASL snippet that should give an idea about how the device
object for UCSI should look like:

Device ()
{
Name (_HID, EISAID("USBC000"))
Name (_CID, EISAID("PNP0CA0"))
Name (_UID, 1)
Name (_DDN, "USB Type-C")
Name (_ADR, 0x0)
Name (_DEP, Package (0x01)
{
// You probable want to have dependency on EC.
})
...

// This will give the OPM (the driver) access to the mailbox
Name (CRS, ResourceTemplate()
{
Memory32Fixed(ReadWrite, 0x12345678, 0x1000, )
})

// This will just give other ACPI methods access to the mailbox
OperationRegion (USBC, SystemMemory, 0x12345678, 0x30)
Field (USBC,AnyAcc,Lock,Preserve)
{
VERS,  16, // PPM->OPM Version
,  16, // Reserved
CCI,   32, // PPM->OPM CCI indicator
CTRL,  64, // OPM->PPM Control message
MSGI, 128, // OPM->PPM Message In
MSGO, 128, // PPM->OPM Message Out
}

Method (_DSM, 4, Serialized)
{
If (LEqual(Arg0, ToUUID 
("6f8398c2-7ca4-11e4-ad36-631042b5008f")))
{
// Here you will probable need the OpRegion
...
}
}
}


I hope that helps!


Br,

-- 
heikki
--
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

Re: [PATCH 2/2] usb: xhci: remove dummy extra_priv_size for size of xhci_hcd struct

[Thierry Reding]

On Tue, Mar 07, 2017 at 11:32:23AM +0800, Chunfeng Yun wrote:
> because hcd_priv_size is already size of xhci_hcd struct,
> extra_priv_size is not needed anymore for MTK and tegra drivers.
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/usb/host/xhci-mtk.c   |1 -
>  drivers/usb/host/xhci-tegra.c |1 -
>  2 files changed, 2 deletions(-)

For Tegra:

Tested-by: Thierry Reding 
Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t

[Sergei Shtylyov]

On 3/7/2017 10:52 AM, Reshetova, Elena wrote:


refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Signed-off-by: Elena Reshetova 
Signed-off-by: Hans Liljestrand 
Signed-off-by: Kees Cook 
Signed-off-by: David Windsor 

[...]

diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
index 115414c..16c1313 100644
--- a/drivers/media/pci/cx88/cx88.h
+++ b/drivers/media/pci/cx88/cx88.h

[...]

@@ -339,7 +340,7 @@ struct cx8802_dev;

 struct cx88_core {
struct list_head   devlist;
-   atomic_t   refcount;
+   refcount_t   refcount;


Could you please keep the name aligned with above and below?


You mean "not aligned" to devlist, but with a shift like it was before?


   I mean aligned, like it was before. :-)


Sure, will fix. Is the patch ok otherwise?


   I haven't noticed anything else...


Best Regards,
Elena.

[...]

MBR, Sergei
--
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

Re: usb: gadget: webcam broken?

[Roger Quadros]

--
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

Re: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

On 3 March 2017 at 10:23, NeilBrown  wrote:
> On Mon, Feb 20 2017, Baolin Wang wrote:
>
>> Currently the Linux kernel does not provide any standard integration of this
>> feature that integrates the USB subsystem with the system power regulation
>> provided by PMICs meaning that either vendors must add this in their kernels
>> or USB gadget devices based on Linux (such as mobile phones) may not behave
>> as they should. Thus provide a standard framework for doing this in kernel.
>>
>> Now introduce one user with wm831x_power to support and test the usb charger.
>> Another user introduced to support charger detection by Jun Li:
>> https://www.spinics.net/lists/linux-usb/msg139425.html
>> Moreover there may be other potential users will use it in future.
>>
>> 1. Before v19 patchset we've fixed below issues in extcon subsystem and usb
>> phy driver, now all were merged. (Thanks for Neil's suggestion)
>> (1) Have fixed the inconsistencies with USB connector types in extcon 
>> subsystem
>> by following links:
>> https://lkml.org/lkml/2016/12/21/13
>> https://lkml.org/lkml/2016/12/21/15
>> https://lkml.org/lkml/2016/12/21/79
>> https://lkml.org/lkml/2017/1/3/13
>>
>> (2) Instead of using 'set_power' callback in phy drivers, we will introduce
>> USB charger to set PMIC current drawn from USB configuration, moreover some
>> 'set_power' callbacks did not implement anything to set PMIC current, thus
>> remove them by following links:
>> https://lkml.org/lkml/2017/1/18/436
>> https://lkml.org/lkml/2017/1/18/439
>> https://lkml.org/lkml/2017/1/18/438
>> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c) still
>> used 'set_power' callback to set current, we can remove them in future. (I
>> have no platform with enabling these two phy drivers, so I can not test them
>> if I converted 'set_power' callback to USB charger.)
>>
>> 2. Some issues pointed by Neil Brown were sill kept in this v19 patchset, and
>> I expalined each issue and may be need discuss again:
>> (1) Change all usb phys to register an extcon and to send appropriate 
>> notifications.
>> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c, phy-omap-otg.c and
>> phy-msm-usb.c) had registered an extcon, mostly did not. I can not change all
>> usb phys to register an extcon, since there are no extcon device to register
>> for these different phy drivers.
>
> You don't have to change every driver.  You just need to make it easy
> and obvious how to change drivers in a consistent coherent way.
> For a start you would add a 'struct extcon_dev' to 'struct usb_phy', and
> possibly add or extend some 'static inline's in linux/usb/phy.h to send
> notification on that extcon (if it is non-NULL).
> e.g. usb_phy_vbus_on() could send an extcon notification.
>
> Then any phy driver which adds support for setting phy->extcon_dev
> appropriately, immediately gets the relevant notifications sent.

OK. We can make these extcon related code into phy common part.

>
>> Secondly, I also agreed with Peter's comments: Not only USB PHY to register
>> an extcon, but also for the drivers which can detect USB charger type, it may
>> be USB controller driver, USB type-c driver, pmic driver, and these drivers
>> may not have an extcon device since the internal part can finish the vbus
>> detect.
>
> Whichever part can detect vbus, the driver for that part must be able to
> find the extcon and trigger a notification.
> Maybe one part can detect VBUS, another can measure the resistance on ID
> and a third can work through the state machine to determine if D+ and D-
> are shorted together.
> Somehow these three need to work together to determine what is plugged
> in to the external connection port.  Somewhere there much an 'extcon'
> device which represents that port and which the three devices can find
> and can interact with.
> I think it makes sense for the usb_phy to be the connection point.  Each
> of the devices can get to the phy, and the phy can get to the extcon.
> It doesn't matter very much if the usb phy driver creates the extcon, or
> if something else creates the extcon and the phy driver performs a
> lookup to find it (e.g. based on devicetree info).
>
> The point is that there is obviously an external physical connection,
> and so there should be an 'extcon' device that represents it.

Peter & Jun, is it OK for you every phy has one extcon device to
receive VBUS notification, especially for detecting the charger type
by software?

>
>>
>> (2) Change the notifier of usb_phy to be used consistently.
>> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and 
>> phy-gpio-vbus-usb.c)
>> used the notifier of usb_phy. phy-generic.c and phy-gpio-vbus-usb.c were 
>> used to
>> send out the connect events, and phy-ab8500-usb.c also was used to send out 
>> the
>> MUSB connect events. There are no phy drivers will notify 'vbus_draw' 
>> information
>> by the notifier of usb_phy, which was used consistently now.
>> Moreover it is 

Re: Question: Does usbip support USB 3.0?

[Krzysztof Opasiak]

On 03/07/2017 01:52 AM, Yuyang Du wrote:

Hi Greg,

On Mon, Mar 06, 2017 at 11:05:47AM +0100, Greg KH wrote:

I did the experiment. Our device "requires" that the SUPER_SPPED be used.
So, we are attempting to add SUPER_SPEED support to usbip. To assess the
effort, could you please give us some pointers on how to do it? And what
are the difficulties?


As others have pointed out, you will have to change the code to do this,
and it will be easier if you only need a speed change, and not streams.
But why do you really need a speed indicator?  What happens if you just
report that the device is "high speed" to the host instead?  It should
not affect the transmit speeds, right?


I don't understand how to just "report" the device as "high speed". Doesn't
the device specify which speed? Moreover, it seems the device doesn't compromise
on speed - when I inserted it into a USB 2.0 port, it doesn't work.


Does dmesg says sth why new device cannot be enumerated?

If it' not some "top secret" device maybe try to send us descriptors 
(lsusb -vd VID:PID)?


Best regards,
--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
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

Re: Question: Does usbip support USB 3.0?

[Krzysztof Opasiak]

Hi,

On 03/07/2017 01:43 AM, Yuyang Du wrote:

( ... )


There is also other side, the protocol. Probably we won't be able to
handle this using exiting protocol messages. At first glance I see
at least one reason:

Documentation/usb/usbip_protocol.txt:

USBIP_RET_SUBMIT: Reply for submitting an URB

 Offset| Length | Value  | Description
---+++---
 0 | 4  | 0x0003 | command
---+++---
 4 | 4  || seqnum: URB sequence number
---+++---
 8 | 4  || devid
---+++---
 0xC   | 4  || direction: 0: USBIP_DIR_OUT
   |||1: USBIP_DIR_IN
---+++---
 0x10  | 4  || ep: endpoint number
---+++---
 0x14  | 4  || status: zero for successful URB
transaction,
   |||   otherwise some kind of error happened.
---+++---
 0x18  | 4  | n  | actual_length: number of URB data bytes
---+++---
 0x1C  | 4  || start_frame: for an ISO frame the
actually
   |||   selected frame for transmit.
---+++---
 0x20  | 4  || number_of_packets
---+++---
 0x24  | 4  || error_count
---+++---
 0x28  | 8  || setup: data bytes for USB setup,
filled with
   |||   zeros if not used
---+++---
 0x30  | n  || URB data bytes. For ISO transfers
the padding
   |||   between each ISO packets is not
transmitted.



As you see we have a field for devid, direction and ep but we don't
have a field for stream id.


Then, as Oliver pointed out, if we don't need bulk streams transfer type, the
current protocol should work fine, right?


Yeah it should or at least for now I don't see any obvious reason why it 
could not work.


Cheers,
--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
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

Re: [PATCH v17 2/3] usb: USB Type-C connector class

[Heikki Krogerus]

On Tue, Mar 07, 2017 at 01:36:29AM +, Peter Chen wrote:
> >On Mon, Mar 06, 2017 at 09:15:51AM +0800, Peter Chen wrote:
> >> > > What interface you use when you receive this event to handle
> >> > > dual-role switch? I am wonder if a common dual-role class is
> >> > > needed, then we can have a common user utility.
> >> > >
> >> > > Eg, if "data_role" has changed, the udev can echo "data_role" to
> >> > > /sys/class/usb-dual-role/role
> >> >
> >> > No. If the partner executes successfully for example DR_Swap
> >> > message, the kernel has to take care everything that is needed for
> >> > the role to be what ever was negotiated on its own. User space can't
> >> > be involved with that.
> >> >
> >>
> >> Would you give me an example how kernel handle this? How type-C event
> >> triggers role switch?
> >
> >On our boards, the firmware or EC (or ACPI) configures the hardware as needed
> >and also notifies the components using ACPI if needed. It's often not even 
> >possible to
> >directly configure the components/hardware for a particular role.
> >
> 
> You mean type-C trigger an ACPI event, and this ACPI event can notify related
> USB controller driver doing role switch?

No (firmware programs the dual-role hw/registers), but never mind.
That could be the case.

> If it is correct, there is a notifier between type-C
> and USB controller driver, how to define this notifier for non-ACPI platform? 

Once there is a platform with Type-C like that, the problem needs to
be solved. However..

> >I'm not commenting on Roger's dual role patch series, but I don't really 
> >think it should
> >be mixed with Type-C. USB Type-C and USB Power Delivery define their own ways
> >of handling the roles, and they are not limited to the data role only. 
> >Things like OTG
> >for example will, and actually can not be supported. With Type-C we will have
> >competing state machines compared to OTG. The dual-role framework may be
> >useful on systems that provide more traditional connectors, which possibly 
> >have the
> >ID-pin like micro-AB, and possibly also support OTG. It can also be 
> >something that
> >exist in parallel with the Type-C class, but there just can not be any 
> >dependencies
> >between the two.
> >
> 
> Yes, there are two independent things. But if the kernel doesn't have a 
> notifier between
> type-C message sender (type-c class) and message receiver (like USB 
> controller driver
> for role switch or other drivers for alternate mode message), we had to find 
> some ways at
> userspace.

..what ever the solution is, it really can't rely on user space.


Thanks,

-- 
heikki
--
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

[PATCH] usb: gadget: uvc: Missing files for configfs interface

[Petr Cvek]

Commit 76e0da34c7ce ("usb-gadget/uvc: use per-attribute show and store
methods") caused a stringification of an undefined macro argument "aname",
so three UVC parameters (streaming_interval, streaming_maxpacket and
streaming_maxburst) were named "aname".

Add the definition of "aname" to the main macro and name the filenames as
originaly intended.

Signed-off-by: Petr Cvek 
---
 drivers/usb/gadget/function/uvc_configfs.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/function/uvc_configfs.c 
b/drivers/usb/gadget/function/uvc_configfs.c
index 4e037d2a7a60..3a36b2e85788 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -2125,7 +2125,7 @@ static struct configfs_item_operations uvc_item_ops = {
.release= uvc_attr_release,
 };
 
-#define UVCG_OPTS_ATTR(cname, conv, str2u, uxx, vnoc, limit)   \
+#define UVCG_OPTS_ATTR(cname, aname, conv, str2u, uxx, vnoc, limit)\
 static ssize_t f_uvc_opts_##cname##_show(  \
struct config_item *item, char *page)   \
 {  \
@@ -2172,12 +2172,12 @@ UVC_ATTR(f_uvc_opts_, cname, aname)
 
 #define identity_conv(x) (x)
 
-UVCG_OPTS_ATTR(streaming_interval, identity_conv, kstrtou8, u8, identity_conv,
-  16);
-UVCG_OPTS_ATTR(streaming_maxpacket, le16_to_cpu, kstrtou16, u16, le16_to_cpu,
-  3072);
-UVCG_OPTS_ATTR(streaming_maxburst, identity_conv, kstrtou8, u8, identity_conv,
-  15);
+UVCG_OPTS_ATTR(streaming_interval, streaming_interval, identity_conv,
+  kstrtou8, u8, identity_conv, 16);
+UVCG_OPTS_ATTR(streaming_maxpacket, streaming_maxpacket, le16_to_cpu,
+  kstrtou16, u16, le16_to_cpu, 3072);
+UVCG_OPTS_ATTR(streaming_maxburst, streaming_maxburst, identity_conv,
+  kstrtou8, u8, identity_conv, 15);
 
 #undef identity_conv
 
-- 
2.11.0

--
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

Re: [PATCH 13/29] drivers, media: convert vb2_vmarea_handler.refcount from atomic_t to refcount_t

[Sakari Ailus]

Hi Elena,

On Mon, Mar 06, 2017 at 04:21:00PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
>  drivers/media/v4l2-core/videobuf2-memops.c | 6 +++---
>  include/media/videobuf2-memops.h   | 3 ++-
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-memops.c 
> b/drivers/media/v4l2-core/videobuf2-memops.c
> index 1cd322e..4bb8424 100644
> --- a/drivers/media/v4l2-core/videobuf2-memops.c
> +++ b/drivers/media/v4l2-core/videobuf2-memops.c
> @@ -96,10 +96,10 @@ static void vb2_common_vm_open(struct vm_area_struct *vma)
>   struct vb2_vmarea_handler *h = vma->vm_private_data;
>  
>   pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> -__func__, h, atomic_read(h->refcount), vma->vm_start,
> +__func__, h, refcount_read(h->refcount), vma->vm_start,
>  vma->vm_end);
>  
> - atomic_inc(h->refcount);
> + refcount_inc(h->refcount);
>  }
>  
>  /**
> @@ -114,7 +114,7 @@ static void vb2_common_vm_close(struct vm_area_struct 
> *vma)
>   struct vb2_vmarea_handler *h = vma->vm_private_data;
>  
>   pr_debug("%s: %p, refcount: %d, vma: %08lx-%08lx\n",
> -__func__, h, atomic_read(h->refcount), vma->vm_start,
> +__func__, h, refcount_read(h->refcount), vma->vm_start,
>  vma->vm_end);
>  
>   h->put(h->arg);
> diff --git a/include/media/videobuf2-memops.h 
> b/include/media/videobuf2-memops.h
> index 36565c7a..a6ed091 100644
> --- a/include/media/videobuf2-memops.h
> +++ b/include/media/videobuf2-memops.h
> @@ -16,6 +16,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  /**
>   * struct vb2_vmarea_handler - common vma refcount tracking handler
> @@ -25,7 +26,7 @@
>   * @arg: argument for @put callback
>   */
>  struct vb2_vmarea_handler {
> - atomic_t*refcount;
> + refcount_t  *refcount;

This is a pointer to refcount, not refcount itself. The refcount is part of
a memory type specific struct, the types that you change in the following
three patches. I guess it would still compile and work as separate patches
but you'd sure get warnings at least.

How about merging this and the three following patches that change the memop
refcount types?

>   void(*put)(void *arg);
>   void*arg;
>  };

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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

Re: Question: Does usbip support USB 3.0?

[Yuyang Du]

Hi Greg,

On Mon, Mar 06, 2017 at 11:05:47AM +0100, Greg KH wrote:
> > I did the experiment. Our device "requires" that the SUPER_SPPED be used.
> > So, we are attempting to add SUPER_SPEED support to usbip. To assess the
> > effort, could you please give us some pointers on how to do it? And what
> > are the difficulties?
> 
> As others have pointed out, you will have to change the code to do this,
> and it will be easier if you only need a speed change, and not streams.
> But why do you really need a speed indicator?  What happens if you just
> report that the device is "high speed" to the host instead?  It should
> not affect the transmit speeds, right?
 
I don't understand how to just "report" the device as "high speed". Doesn't
the device specify which speed? Moreover, it seems the device doesn't compromise
on speed - when I inserted it into a USB 2.0 port, it doesn't work.

> Also, there is code within Intel for the USB-over-IP standard
> implementation that should work for this type of device.  I thought
> people were working on cleaning it up for submission to the kernel tree,
> but I haven't seen it in months.  You should dig in the archives for it,
> and work with those developers to get it merged properly, as it should
> resolve your issues.
 
So far, my dig hasn't found anything, but I'll keep looking for/asking...

Thanks,
Yuyang
--
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

Re: USB wifi bug with Ubuntu16.04 LTS 4.4.0-64 kernel

[Greg KH]

On Tue, Mar 07, 2017 at 10:12:15AM +0200, pete wrote:
> Hello,
> 
> this is my first bug report and I tried to collect all the info in the end
> of my email. Sorry if I missed something! The info provided is showing my
> computer with kernel 4.4.0-62 which is working fine. I don't have the same
> data for you with the 4.4.0-64 kernel (because I couldn't connect to
> internet and find help at that point so I just went back to the -62).
> 
> Here's the bug I noted: I updated my Ubuntu kernel from 4.4.0-62 to 4.4.0-64
> today (Ubuntu Software updater prompted to do it) and after reboot my
> computer did not response to any key/mouse/pointer input. Only thing it did
> was caps lock light flashed all the time. After hard boot without the USB
> wifi dongle (König USB 150 Mbps Wlan dongle, CMP-WNUSB32) all worked ok.
> When I put the wifi dongle to computer it freezed as earlier. Only the caps
> lock light was flashing.

You are going to have to file a bug with Ubuntu, we have no idea what
they changed between those two old kernel versions, sorry.

good luck!

greg k-h
--
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

Re: Question: Does usbip support USB 3.0?

[Yuyang Du]

Hi Oliver,

On Mon, Mar 06, 2017 at 10:30:11AM +0100, Oliver Neukum wrote:
> 
> Just SuperSpeed or also streams? Just one more speed is easier than
> a totally new feature.
> 

I think we only need isochronous transfer, so no streams. Hope it's
easier, but I can't call it right now, :)

Thanks,
Yuyang
--
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

Re: [PATCH] uvc-gadget: Fix Set Interface (alternate setting) response behaviour

[Roger Quadros]

Laurent,

On 06/03/17 22:50, Laurent Pinchart wrote:
> Hi Roger,
> 
> Thank you for the patch.
> 
> On Friday 03 Mar 2017 13:17:15 Roger Quadros wrote:
>> On alternate setting change, webcam gadget sends us a UVC_EVENT_STREAMON
>> or UVC_EVENT_STREAMOFF event. It expects delayed status response on
>> STREAMON event only but doesn't expect us to send that response over USB.
>> It sends the delayed response when we issue the VIDIOC_STREAMON ioctl.
>>
>> So we must not send UVCIOC_SEND_RESPONSE ioctl in these cases that too
>> with invalid response length.
> 
> The commit message only explains why we should not call UVCIOC_SEND_RESPONSE 
> in response to a STREAMON event, but not why we shouldn't either in response 
> to a STREAMOFF event. The patch is correct changing both, but I propose 
> wording the above two paragraphs as follows.
> 
> "uvc-gadget: Do not send Set Interface (alternate setting) response twice
> 
> On alternate setting change, the webcam gadget sends us a UVC_EVENT_STREAMON 
> or UVC_EVENT_STREAMOFF event. In the first case, the driver will issue a 
> delayed status response automatically when we call the VIDIOC_STREAMON ioctl. 
> In the second case, the driver sends the status response immediately. We must 
> thus not send the status response manually with UVCIOC_SEND_RESPONSE in any 
> of 
> those cases."
> 
> If you're fine with that I'll change the message when applying, there's no 
> need to resend the patch.

I'm fine with your suggested commit message. Thanks.

> 
>> Without this, the ISO streaming doesn't work if host application
>> (e.g. luvcview) is closed and restarted.
>> On dwc3 gadget controller it was resulting in Buffer Expiry error on
>> the ISO endpoint.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  uvc-gadget.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/uvc-gadget.c b/uvc-gadget.c
>> index 9ef315c..4d59ab8 100644
>> --- a/uvc-gadget.c
>> +++ b/uvc-gadget.c
>> @@ -597,12 +597,12 @@ uvc_events_process(struct uvc_device *dev)
>>  case UVC_EVENT_STREAMON:
>>  uvc_video_reqbufs(dev, 4);
>>  uvc_video_stream(dev, 1);
>> -break;
>> +return;
>>
>>  case UVC_EVENT_STREAMOFF:
>>  uvc_video_stream(dev, 0);
>>  uvc_video_reqbufs(dev, 0);
>> -break;
>> +return;
>>  }
>>
>>  ioctl(dev->fd, UVCIOC_SEND_RESPONSE, );
> 

-- 
cheers,
-roger
--
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

Re: [PATCH 12/29] drivers, media: convert s2255_dev.num_channels from atomic_t to refcount_t

[Sakari Ailus]

Hi Elena,

On Mon, Mar 06, 2017 at 04:20:59PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
...
> @@ -1688,7 +1689,7 @@ static int s2255_probe_v4l(struct s2255_dev *dev)
>   "failed to register video device!\n");
>   break;
>   }
> - atomic_inc(>num_channels);
> + refcount_set(>num_channels, 1);

That's not right. The loop runs four iterations and the value after the
loop should be indeed the number of channels.

atomic_t isn't really used for reference counting here, but storing out how
many "channels" there are per hardware device, with maximum number of four
(4). I'd leave this driver using atomic_t.

>   v4l2_info(>v4l2_dev, "V4L2 device registered as %s\n",
> video_device_node_name(>vdev));
>  

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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

Re: [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t

[Sakari Ailus]

On Mon, Mar 06, 2017 at 04:20:58PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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

Re: [PATCH v4 0/3] dmaengine: cppi41: Add dma support to da8xx

[Vinod Koul]

On Mon, Jan 30, 2017 at 06:49:18PM +0100, Alexandre Bailon wrote:
> This series add support of DA8xx to CPPI 4.1 driver.
> As the CPPI 4.1 is now generic, we only had to add the glue for DA8xx.

Applied this one as well, thanks

-- 
~Vinod
--
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

USB wifi bug with Ubuntu16.04 LTS 4.4.0-64 kernel

[pete]

Hello,

this is my first bug report and I tried to collect all the info in the 
end of my email. Sorry if I missed something! The info provided is 
showing my computer with kernel 4.4.0-62 which is working fine. I don't 
have the same data for you with the 4.4.0-64 kernel (because I couldn't 
connect to internet and find help at that point so I just went back to 
the -62).


Here's the bug I noted: I updated my Ubuntu kernel from 4.4.0-62 to 
4.4.0-64 today (Ubuntu Software updater prompted to do it) and after 
reboot my computer did not response to any key/mouse/pointer input. Only 
thing it did was caps lock light flashed all the time. After hard boot 
without the USB wifi dongle (König USB 150 Mbps Wlan dongle, 
CMP-WNUSB32) all worked ok. When I put the wifi dongle to computer it 
freezed as earlier. Only the caps lock light was flashing.


I removed the 4.4.0-64 kernel from my computer and continue with the -62 
version for now :)


Best regards,
Pete


Here's the info I assume you'll need:

uname -a
Linux pete 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux




cat /proc/version_signature
Ubuntu 4.4.0-62.83-generic 4.4.40




dmesg
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.4.0-62-generic (buildd@lcy01-30) (gcc 
version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #83-Ubuntu SMP 
Wed Jan 18 14:10:15 UTC 2017 (Ubuntu 4.4.0-62.83-generic 4.4.40)
[0.00] Command line: 
BOOT_IMAGE=/boot/vmlinuz-4.4.0-62-generic.efi.signed 
root=UUID=0f1c4557-4e5f-4f12-894c-e6eeb650a63c ro quiet splash vt.handoff=7

[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'lazy' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0006efff] usable
[0.00] BIOS-e820: [mem 0x0006f000-0x0006] 
ACPI NVS

[0.00] BIOS-e820: [mem 0x0007-0x00085fff] usable
[0.00] BIOS-e820: [mem 0x00086000-0x0009] 
reserved

[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] 
reserved

[0.00] BIOS-e820: [mem 0x2020-0x7605] usable
[0.00] BIOS-e820: [mem 0x7606-0x7625] 
type 20
[0.00] BIOS-e820: [mem 0x7626-0x76a5] 
reserved
[0.00] BIOS-e820: [mem 0x76a6-0x76c5] 
ACPI NVS
[0.00] BIOS-e820: [mem 0x76c6-0x76c9] 
ACPI data

[0.00] BIOS-e820: [mem 0x76ca-0x77ff] usable
[0.00] BIOS-e820: [mem 0xe00f8000-0xe00f8fff] 
reserved
[0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] 
reserved
[0.00] BIOS-e820: [mem 0xffa0-0x] 
reserved

[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.40 by INSYDE Corp.
[0.00] efi:  ACPI 2.0=0x76c9f014  SMBIOS=0x763ec000 ESRT=0x763f1118
[0.00] esrt: Reserving ESRT space from 0x763f1118 to 
0x763f1150.

[0.00] SMBIOS 2.8 present.
[0.00] DMI: HP HP Stream Notebook PC 13 /817D, BIOS F.1B 01/05/2016
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x78000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0FFC0 mask FFFC0 write-protect
[0.00]   1 base 0FFA0 mask FFFE0 write-protect
[0.00]   2 base 0 mask F8000 write-back
[0.00]   3 base 07C00 mask FFC00 uncachable
[0.00]   4 base 07BC0 mask FFFC0 uncachable
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC UC- WT
[0.00] Scanning 1 areas for low memory corruption
[0.00] Base memory trampoline at [8807b000] 7b000 size 24576
[0.00] BRK [0x0320b000, 0x0320bfff] PGTABLE
[0.00] BRK [0x0320c000, 0x0320cfff] PGTABLE
[0.00] BRK [0x0320d000, 0x0320dfff] PGTABLE
[0.00] BRK [0x0320e000, 0x0320efff] PGTABLE
[0.00] BRK [0x0320f000, 0x0320] PGTABLE
[0.00] BRK [0x0321, 0x03210fff] PGTABLE
[0.00] RAMDISK: [mem 0x3379c000-0x35bc5fff]
[0.00] ACPI: 

Re: [PATCH v5 0/5] dmaengine: cppi41: Make CPPI 4.1 driver more generic

[Vinod Koul]

On Wed, Feb 15, 2017 at 02:56:31PM +0100, Alexandre Bailon wrote:
> This series intend to make the CPPI 4.1 more generic in order to
> add a new platform (the DA8xx).
> To achieve that, all the IRQ code present in CPPI 4.1 driver has been moved
> to MUSB DSPS driver.
> Other changes mainly update the glue layer and platform code to make the
> whole driver more generic.

Applied thanks

-- 
~Vinod
--
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

RE: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t

[Reshetova, Elena]

> On 03/06/2017 03:21 PM, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> 
> The subject is wrong, should be something like "scsi: libfc convert
> fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390.

Very sorry about this: the error in the subject got from the time when I was 
trying to break the bigger drivers patch set into per-variable part and trying 
to automate the process too much :(
I will fix it in the end version!

Best Regards,
Elena

> 
> Other than that
> Acked-by: Johannes Thumshirn 
> 
> --
> Johannes Thumshirn  Storage
> jthumsh...@suse.de+49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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

RE: [PATCH 11/29] drivers, media: convert cx88_core.refcount from atomic_t to refcount_t

[Reshetova, Elena]

> Hello.
> 
> On 03/06/2017 05:20 PM, Elena Reshetova wrote:
> 
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> [...]
> > diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
> > index 115414c..16c1313 100644
> > --- a/drivers/media/pci/cx88/cx88.h
> > +++ b/drivers/media/pci/cx88/cx88.h
> > @@ -24,6 +24,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > @@ -339,7 +340,7 @@ struct cx8802_dev;
> >
> >  struct cx88_core {
> > struct list_head   devlist;
> > -   atomic_t   refcount;
> > +   refcount_t   refcount;
> 
> Could you please keep the name aligned with above and below?

You mean "not aligned" to devlist, but with a shift like it was before? 
Sure, will fix. Is the patch ok otherwise?

Best Regards,
Elena.

> 
> >
> > /* board name */
> > intnr;
> >
> 
> MBR, Sergei

N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�