Re: linux-next build broken for renesas-usb3?

2018-08-09 Thread Felipe Balbi

Hi Yoshihiro,

John Garry  writes:
> Hi all,
>
> I am finding the following build error on today's next build:
>MODPOST 395 modules
> ERROR: "usb_of_get_companion_dev" 
> [drivers/usb/gadget/udc/renesas_usb3.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> I was using arm64 defconfig, but disabled some USB-related configs 
> including CONFIG_USB, which I think is my problem (USB options at the 
> bottom).
>
> So this patch may be the issue:
> commit 39facfa01c9fc64f90233d1734882f0a0cafe36a
> Author: Yoshihiro Shimoda 
> Date:   Fri Jul 27 10:50:40 2018 +0900
>
>  usb: gadget: udc: renesas_usb3: Add register of usb role switch
>
> I do notice this message at the top of the Kconfig associated with this 
> driver:
> NOTE:  Gadget support ** DOES NOT ** depend on host-side CONFIG_USB !!
>
> Sorry for the noise if I'm mistaken or already reported.

Any ideas?



> # CONFIG_USB_SWITCH_FSA9480 is not set
> # Host-side USB support is needed for USB Network Adapter support
> # CONFIG_MOUSE_SYNAPTICS_USB is not set
> # CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
> CONFIG_PINCTRL_TEGRA_XUSB=y
> # CONFIG_CHARGER_CROS_USBPD is not set
> # CONFIG_IR_MCEUSB is not set
> # CONFIG_IR_IGORPLUGUSB is not set
> # CONFIG_IR_TTUSBIR is not set
> CONFIG_USB_OHCI_LITTLE_ENDIAN=y
> CONFIG_USB_SUPPORT=y
> CONFIG_USB_COMMON=y
> CONFIG_USB_ARCH_HAS_HCD=y
> # CONFIG_USB is not set
> CONFIG_USB_PCI=y
> # CONFIG_USB_MTU3 is not set
> CONFIG_USB_MUSB_HDRC=y
> CONFIG_USB_MUSB_GADGET=y
> CONFIG_USB_MUSB_SUNXI=y
> # MUSB DMA mode
> # CONFIG_MUSB_PIO_ONLY is not set
> # CONFIG_USB_DWC3 is not set
> # CONFIG_USB_DWC2 is not set
> CONFIG_USB_CHIPIDEA=y
> CONFIG_USB_CHIPIDEA_OF=y
> CONFIG_USB_CHIPIDEA_PCI=y
> CONFIG_USB_CHIPIDEA_UDC=y
> CONFIG_USB_ISP1760=y
> CONFIG_USB_ISP1761_UDC=y
> CONFIG_USB_ISP1760_GADGET_ROLE=y
> # USB port drivers
> # USB Physical Layer drivers
> CONFIG_USB_PHY=y
> CONFIG_NOP_USB_XCEIV=y
> # CONFIG_USB_GPIO_VBUS is not set
> # CONFIG_USB_ISP1301 is not set
> # CONFIG_USB_TEGRA_PHY is not set
> CONFIG_USB_ULPI=y
> CONFIG_USB_ULPI_VIEWPORT=y
> CONFIG_USB_GADGET=y
> # CONFIG_USB_GADGET_DEBUG is not set
> # CONFIG_USB_GADGET_DEBUG_FILES is not set
> # CONFIG_USB_GADGET_DEBUG_FS is not set
> CONFIG_USB_GADGET_VBUS_DRAW=2
> CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
> # USB Peripheral Controller
> # CONFIG_USB_FOTG210_UDC is not set
> # CONFIG_USB_GR_UDC is not set
> # CONFIG_USB_R8A66597 is not set
> CONFIG_USB_RENESAS_USB3=m
> # CONFIG_USB_PXA27X is not set
> # CONFIG_USB_MV_UDC is not set
> # CONFIG_USB_MV_U3D is not set
> CONFIG_USB_SNP_CORE=y
> CONFIG_USB_SNP_UDC_PLAT=y
> # CONFIG_USB_M66592 is not set
> CONFIG_USB_BDC_UDC=y
> CONFIG_USB_BDC_PCI=y
> # CONFIG_USB_AMD5536UDC is not set
> # CONFIG_USB_NET2272 is not set
> # CONFIG_USB_NET2280 is not set
> # CONFIG_USB_GOKU is not set
> # CONFIG_USB_EG20T is not set
> # CONFIG_USB_GADGET_XILINX is not set
> # CONFIG_USB_CONFIGFS is not set
> # CONFIG_USB_LED_TRIG is not set
> CONFIG_USB_ULPI_BUS=y
> CONFIG_USB_ROLE_SWITCH=m
> # LED driver for blink(1) USB RGB LED is under Special HID drivers 
> (HID_THINGM)
> CONFIG_RENESAS_USB_DMAC=m
> # CONFIG_CLK_RCAR_USB2_CLOCK_SEL is not set
> CONFIG_EXTCON_USB_GPIO=y
> CONFIG_EXTCON_USBC_CROS_EC=y
> CONFIG_RESET_UNIPHIER_USB3=y
> CONFIG_PHY_SUN4I_USB=y
> # CONFIG_PHY_SUN9I_USB is not set
> CONFIG_PHY_MESON8B_USB2=y
> CONFIG_PHY_MESON_GXL_USB2=y
> CONFIG_PHY_MESON_GXL_USB3=y
> # CONFIG_BCM_KONA_USB2_PHY is not set
> # CONFIG_PHY_BCM_NS_USB2 is not set
> # CONFIG_PHY_BCM_NS_USB3 is not set
> CONFIG_PHY_NS2_USB_DRD=y
> CONFIG_PHY_BRCM_USB=y
> CONFIG_PHY_HI6220_USB=y
> CONFIG_PHY_HISI_INNO_USB2=y
> # CONFIG_PHY_BERLIN_USB is not set
> # CONFIG_PHY_PXA_28NM_USB2 is not set
> # CONFIG_PHY_CPCAP_USB is not set
> # CONFIG_PHY_QCOM_QUSB2 is not set
> CONFIG_PHY_QCOM_USB_HS=y
> # CONFIG_PHY_QCOM_USB_HSIC is not set
> CONFIG_PHY_RCAR_GEN3_USB2=y
> CONFIG_PHY_RCAR_GEN3_USB3=m
> CONFIG_PHY_ROCKCHIP_INNO_USB2=y
> # CONFIG_PHY_ROCKCHIP_USB is not set
> CONFIG_PHY_TEGRA_XUSB=y
> # CONFIG_PHY_TUSB1210 is not set

-- 
balbi


signature.asc
Description: PGP signature


[PATCH] Add quirk to support DJI CineSSD

2018-08-09 Thread Tim Anderson
This device does not correctly handle the LPM operations.

Also, the device cannot handle ATA pass-through commands
and locks up when attempted while running in super speed.

This patch adds the equivalent quirk logic as found in uas.

Signed-off-by: Tim Anderson 
---
 drivers/usb/core/quirks.c  | 3 +++
 drivers/usb/storage/scsiglue.c | 9 +
 drivers/usb/storage/unusual_devs.h | 7 +++
 3 files changed, 19 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 097057d..560ce25 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -406,6 +406,9 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x2040, 0x7200), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
 
+   /* DJI CineSSD */
+   { USB_DEVICE(0x2ca3, 0x0031), .driver_info = USB_QUIRK_NO_LPM },
+
/* INTEL VALUE SSD */
{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
 
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index c267f28..e227bb5 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -376,6 +376,15 @@ static int queuecommand_lck(struct scsi_cmnd *srb,
return 0;
}
 
+   if ((us->fflags & US_FL_NO_ATA_1X) &&
+   (srb->cmnd[0] == ATA_12 || srb->cmnd[0] == ATA_16)) {
+   memcpy(srb->sense_buffer, usb_stor_sense_invalidCDB,
+  sizeof(usb_stor_sense_invalidCDB));
+   srb->result = SAM_STAT_CHECK_CONDITION;
+   done(srb);
+   return 0;
+   }
+
/* enqueue the command and wake up the control thread */
srb->scsi_done = done;
us->srb = srb;
diff --git a/drivers/usb/storage/unusual_devs.h 
b/drivers/usb/storage/unusual_devs.h
index 22fcfcc..f7f83b21 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2288,6 +2288,13 @@ UNUSUAL_DEV(  0x2735, 0x100b, 0x, 0x,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_GO_SLOW ),
 
+/* Reported-by: Tim Anderson  */
+UNUSUAL_DEV(  0x2ca3, 0x0031, 0x, 0x,
+   "DJI",
+   "CineSSD",
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_NO_ATA_1X),
+
 /*
  * Reported by Frederic Marchal 
  * Mio Moov 330
-- 
2.7.5



Re: [PATCH] usbip: Fix misuse of strncpy()

2018-08-09 Thread Shuah Khan
On 07/26/2018 04:39 AM, Ben Hutchings wrote:
> On Tue, 2018-07-24 at 11:04 -0600, Shuah Khan wrote:
>> On 07/20/2018 08:12 PM, Ben Hutchings wrote:
>>> gcc 8 reports:
>>>
>>> usbip_device_driver.c: In function ‘read_usb_vudc_device’:
>>> usbip_device_driver.c:106:2: error: ‘strncpy’ specified bound 256 equals 
>>> destination size [-Werror=stringop-truncation]
>>>   strncpy(dev->path, path, SYSFS_PATH_MAX);
>>>   ^~~~
>>> usbip_device_driver.c:125:2: error: ‘strncpy’ specified bound 32 equals 
>>> destination size [-Werror=stringop-truncation]
>>>   strncpy(dev->busid, name, SYSFS_BUS_ID_SIZE);
>>>   ^~~~
>>>
>>> I'm not convinced it makes sense to truncate the copied strings here,
>>> but since we're already doing so let's ensure they're still null-
>>> terminated.  We can't easily use strlcpy() here, so use snprintf().
>>>
>>> usbip_common.c has the same problem.
>>>
>>> Signed-off-by: Ben Hutchings 
>>> Cc: sta...@vger.kernel.org
>>> ---
>>>  tools/usb/usbip/libsrc/usbip_common.c|4 ++--
>>>  tools/usb/usbip/libsrc/usbip_device_driver.c |4 ++--
>>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> --- a/tools/usb/usbip/libsrc/usbip_common.c
>>> +++ b/tools/usb/usbip/libsrc/usbip_common.c
>>> @@ -226,8 +226,8 @@ int read_usb_device(struct udev_device *
>>> path = udev_device_get_syspath(sdev);
>>> name = udev_device_get_sysname(sdev);
>>>  
>>> -   strncpy(udev->path,  path,  SYSFS_PATH_MAX);
>>> -   strncpy(udev->busid, name, SYSFS_BUS_ID_SIZE);
>>> +   snprintf(udev->path, SYSFS_PATH_MAX, "%s", path);
>>> +   snprintf(udev->busid, SYSFS_BUS_ID_SIZE, "%s", name);
>>
>> I am okay with the change to use snprintf(). Please add check for
>> return to avoid GCC 7 -Wformat-overflow wanrs on snprintf instances
>> that don't check return.
> [...]
> 
> I've tried running:
> 
> ./autogen.sh
> CC=gcc-7 CFLAGS=-Wformat-overflow ./configure 
> make
> 
> but this didn't produce any warnings.  How did you get the warning?
> 
> Ben.
> 

Sorry for the delay. It has been a busy few weeks with travel both
vacation and business.

Okay. Please check the e5dfa3f902b9a642ae8c6997d57d7c41e384a90b for
details. I didn't see this problem myself, likely because I was using
older gcc.

thanks,
-- Shuah

thanks,
-- Shuah
--
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 v2 1/2] usb storage: group dependent USB storage Kconfig entries together

2018-08-09 Thread Alan Stern
On Thu, 9 Aug 2018, Vladimir Zapolskiy wrote:

> Instead of explicit setting of USB_STORAGE dependency for every
> underlying build entries, exploit if USB_STORAGE / endif block.
> 
> The change is a trivial non-functional cleanup, it shortens
> the Kconfig file and it is expected to reduce zconf parser
> workload a little.
> 
> Dependencies of USB_UAS build option are left aside deliberately.
> 
> Signed-off-by: Vladimir Zapolskiy 
> ---

For both patches in this series:

Acked-by: 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 v2 1/2] usb storage: group dependent USB storage Kconfig entries together

2018-08-09 Thread Vladimir Zapolskiy
Instead of explicit setting of USB_STORAGE dependency for every
underlying build entries, exploit if USB_STORAGE / endif block.

The change is a trivial non-functional cleanup, it shortens
the Kconfig file and it is expected to reduce zconf parser
workload a little.

Dependencies of USB_UAS build option are left aside deliberately.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/usb/storage/Kconfig | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/storage/Kconfig b/drivers/usb/storage/Kconfig
index ec84758..8d7d764 100644
--- a/drivers/usb/storage/Kconfig
+++ b/drivers/usb/storage/Kconfig
@@ -23,16 +23,16 @@ config USB_STORAGE
  To compile this driver as a module, choose M here: the
  module will be called usb-storage.
 
+if USB_STORAGE
+
 config USB_STORAGE_DEBUG
bool "USB Mass Storage verbose debug"
-   depends on USB_STORAGE
help
  Say Y here in order to have the USB Mass Storage code generate
  verbose debugging messages.
 
 config USB_STORAGE_REALTEK
tristate "Realtek Card Reader support"
-   depends on USB_STORAGE
help
  Say Y here to include additional code to support the power-saving 
function
  for Realtek RTS51xx USB card readers.
@@ -46,7 +46,6 @@ config REALTEK_AUTOPM
 
 config USB_STORAGE_DATAFAB
tristate "Datafab Compact Flash Reader support"
-   depends on USB_STORAGE
help
  Support for certain Datafab CompactFlash readers.
  Datafab has a web page at .
@@ -55,7 +54,6 @@ config USB_STORAGE_DATAFAB
 
 config USB_STORAGE_FREECOM
tristate "Freecom USB/ATAPI Bridge support"
-   depends on USB_STORAGE
help
  Support for the Freecom USB to IDE/ATAPI adaptor.
  Freecom has a web page at .
@@ -64,7 +62,6 @@ config USB_STORAGE_FREECOM
 
 config USB_STORAGE_ISD200
tristate "ISD-200 USB/ATA Bridge support"
-   depends on USB_STORAGE
---help---
  Say Y here if you want to use USB Mass Store devices based
  on the In-Systems Design ISD-200 USB/ATA bridge.
@@ -82,7 +79,6 @@ config USB_STORAGE_ISD200
 
 config USB_STORAGE_USBAT
tristate "USBAT/USBAT02-based storage support"
-   depends on USB_STORAGE
help
  Say Y here to include additional code to support storage devices
  based on the SCM/Shuttle USBAT/USBAT02 processors.
@@ -105,7 +101,6 @@ config USB_STORAGE_USBAT
 
 config USB_STORAGE_SDDR09
tristate "SanDisk SDDR-09 (and other SmartMedia, including DPCM) 
support"
-   depends on USB_STORAGE
help
  Say Y here to include additional code to support the Sandisk SDDR-09
  SmartMedia reader in the USB Mass Storage driver.
@@ -115,7 +110,6 @@ config USB_STORAGE_SDDR09
 
 config USB_STORAGE_SDDR55
tristate "SanDisk SDDR-55 SmartMedia support"
-   depends on USB_STORAGE
help
  Say Y here to include additional code to support the Sandisk SDDR-55
  SmartMedia reader in the USB Mass Storage driver.
@@ -124,7 +118,6 @@ config USB_STORAGE_SDDR55
 
 config USB_STORAGE_JUMPSHOT
tristate "Lexar Jumpshot Compact Flash Reader"
-   depends on USB_STORAGE
help
  Say Y here to include additional code to support the Lexar Jumpshot
  USB CompactFlash reader.
@@ -133,7 +126,6 @@ config USB_STORAGE_JUMPSHOT
 
 config USB_STORAGE_ALAUDA
tristate "Olympus MAUSB-10/Fuji DPC-R1 support"
-   depends on USB_STORAGE
help
  Say Y here to include additional code to support the Olympus MAUSB-10
  and Fujifilm DPC-R1 USB Card reader/writer devices.
@@ -145,7 +137,6 @@ config USB_STORAGE_ALAUDA
 
 config USB_STORAGE_ONETOUCH
tristate "Support OneTouch Button on Maxtor Hard Drives"
-   depends on USB_STORAGE
depends on INPUT=y || INPUT=USB_STORAGE
help
  Say Y here to include additional code to support the Maxtor OneTouch
@@ -160,7 +151,6 @@ config USB_STORAGE_ONETOUCH
 
 config USB_STORAGE_KARMA
tristate "Support for Rio Karma music player"
-   depends on USB_STORAGE
help
  Say Y here to include additional code to support the Rio Karma
  USB interface.
@@ -174,7 +164,6 @@ config USB_STORAGE_KARMA
 
 config USB_STORAGE_CYPRESS_ATACB
tristate "SAT emulation on Cypress USB/ATA Bridge with ATACB"
-   depends on USB_STORAGE
---help---
  Say Y here if you want to use SAT (ata pass through) on devices based
  on the Cypress USB/ATA bridge supporting ATACB. This will allow you
@@ -188,7 +177,6 @@ config USB_STORAGE_CYPRESS_ATACB
 config USB_STORAGE_ENE_UB6250
tristate "USB ENE card reader support"
depends on SCSI
-   depends on USB_STORAGE
---help---
  Say Y here if you wish to control a ENE SD/MS Card reader.
  Note that this dri

[PATCH v2 2/2] usb storage: remove inherited SCSI dependency for USB_STORAGE_ENE_UB6250

2018-08-09 Thread Vladimir Zapolskiy
Because USB_STORAGE build symbol strictly depends on SCSI build
symbol, there is no need to specify it again.

In addition USB_STORAGE_ENE_UB6250 entry description repeats a note
about SCSI dependency from the parent USB_STORAGE entry description,
hence the change removes this duplication.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/usb/storage/Kconfig | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/usb/storage/Kconfig b/drivers/usb/storage/Kconfig
index 8d7d764..6fd4272 100644
--- a/drivers/usb/storage/Kconfig
+++ b/drivers/usb/storage/Kconfig
@@ -176,15 +176,10 @@ config USB_STORAGE_CYPRESS_ATACB
 
 config USB_STORAGE_ENE_UB6250
tristate "USB ENE card reader support"
-   depends on SCSI
---help---
  Say Y here if you wish to control a ENE SD/MS Card reader.
  Note that this driver does not support SM cards.
 
- This option depends on 'SCSI' support being enabled, but you
- probably also need 'SCSI device support: SCSI disk support'
- (BLK_DEV_SD) for most USB storage devices.
-
  To compile this driver as a module, choose M here: the
  module will be called ums-eneub6250.
 
-- 
2.10.2

--
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 storage: group dependent USB storage Kconfig entries together

2018-08-09 Thread Vladimir Zapolskiy
Hi Alan,

thank you for review.

On 08/09/2018 05:01 PM, Alan Stern wrote:
> On Thu, 9 Aug 2018, Vladimir Zapolskiy wrote:
> 
>> Instead of explicit setting of USB_STORAGE dependency for every
>> underlying build entries, exploit if USB_STORAGE / endif block.
>>
>> Signed-off-by: Vladimir Zapolskiy 
> 
> I think this is a worthwhile cleanup, although to make Greg happy you 
> should mention in the description that this shortens the Kconfig file, 
> making it easier to read and less error-prone, with no changes in 
> behavior.

Right, I assumed that the change was quite self-explanatory.

>> @@ -188,7 +177,6 @@ config USB_STORAGE_CYPRESS_ATACB
>>  config USB_STORAGE_ENE_UB6250
>>  tristate "USB ENE card reader support"
>>  depends on SCSI
>> -depends on USB_STORAGE
> 
> You can also remove the "depends on SCSI" line here, since USB_STORAGE
> already depends on SCSI.
> 

Still my intention is to make it in the second change, because at the
same time I remove a duplicated information from a helper note, I hope
it is acceptable.

>> @@ -202,7 +190,7 @@ config USB_STORAGE_ENE_UB6250
>>  
>>  config USB_UAS
>>  tristate "USB Attached SCSI"
>> -depends on SCSI && USB_STORAGE
>> +depends on SCSI
>>  help
>>The USB Attached SCSI protocol is supported by some USB
>>storage devices.  It permits higher performance by supporting
> 
> As Oliver points out, uas is significantly different from all the other 
> entries in this file.  They are sub-drivers for usb-storage, whereas 
> uas is an almost totally separate driver.  Yes, it does depend on 
> usb-storage now, but that's subject to change in the future since the 
> overlap between the two drivers is quite small.
> 
> Just put the UAS portion outside the new conditional region and keep
> its explicit dependencies.
> 

Indeed.

--
Best wishes,
Vladimir
--
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


linux-next build broken for renesas-usb3?

2018-08-09 Thread John Garry

Hi all,

I am finding the following build error on today's next build:
  MODPOST 395 modules
ERROR: "usb_of_get_companion_dev" 
[drivers/usb/gadget/udc/renesas_usb3.ko] undefined!

make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

I was using arm64 defconfig, but disabled some USB-related configs 
including CONFIG_USB, which I think is my problem (USB options at the 
bottom).


So this patch may be the issue:
commit 39facfa01c9fc64f90233d1734882f0a0cafe36a
Author: Yoshihiro Shimoda 
Date:   Fri Jul 27 10:50:40 2018 +0900

usb: gadget: udc: renesas_usb3: Add register of usb role switch

I do notice this message at the top of the Kconfig associated with this 
driver:

NOTE:  Gadget support ** DOES NOT ** depend on host-side CONFIG_USB !!

Sorry for the noise if I'm mistaken or already reported.

Thanks,
John

more .config | grep USB
# CONFIG_USB_SWITCH_FSA9480 is not set
# Host-side USB support is needed for USB Network Adapter support
# CONFIG_MOUSE_SYNAPTICS_USB is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
CONFIG_PINCTRL_TEGRA_XUSB=y
# CONFIG_CHARGER_CROS_USBPD is not set
# CONFIG_IR_MCEUSB is not set
# CONFIG_IR_IGORPLUGUSB is not set
# CONFIG_IR_TTUSBIR is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
# CONFIG_USB is not set
CONFIG_USB_PCI=y
# CONFIG_USB_MTU3 is not set
CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_MUSB_GADGET=y
CONFIG_USB_MUSB_SUNXI=y
# MUSB DMA mode
# CONFIG_MUSB_PIO_ONLY is not set
# CONFIG_USB_DWC3 is not set
# CONFIG_USB_DWC2 is not set
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_OF=y
CONFIG_USB_CHIPIDEA_PCI=y
CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_ISP1760=y
CONFIG_USB_ISP1761_UDC=y
CONFIG_USB_ISP1760_GADGET_ROLE=y
# USB port drivers
# USB Physical Layer drivers
CONFIG_USB_PHY=y
CONFIG_NOP_USB_XCEIV=y
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_TEGRA_PHY is not set
CONFIG_USB_ULPI=y
CONFIG_USB_ULPI_VIEWPORT=y
CONFIG_USB_GADGET=y
# CONFIG_USB_GADGET_DEBUG is not set
# CONFIG_USB_GADGET_DEBUG_FILES is not set
# CONFIG_USB_GADGET_DEBUG_FS is not set
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
# USB Peripheral Controller
# CONFIG_USB_FOTG210_UDC is not set
# CONFIG_USB_GR_UDC is not set
# CONFIG_USB_R8A66597 is not set
CONFIG_USB_RENESAS_USB3=m
# CONFIG_USB_PXA27X is not set
# CONFIG_USB_MV_UDC is not set
# CONFIG_USB_MV_U3D is not set
CONFIG_USB_SNP_CORE=y
CONFIG_USB_SNP_UDC_PLAT=y
# CONFIG_USB_M66592 is not set
CONFIG_USB_BDC_UDC=y
CONFIG_USB_BDC_PCI=y
# CONFIG_USB_AMD5536UDC is not set
# CONFIG_USB_NET2272 is not set
# CONFIG_USB_NET2280 is not set
# CONFIG_USB_GOKU is not set
# CONFIG_USB_EG20T is not set
# CONFIG_USB_GADGET_XILINX is not set
# CONFIG_USB_CONFIGFS is not set
# CONFIG_USB_LED_TRIG is not set
CONFIG_USB_ULPI_BUS=y
CONFIG_USB_ROLE_SWITCH=m
# LED driver for blink(1) USB RGB LED is under Special HID drivers 
(HID_THINGM)

CONFIG_RENESAS_USB_DMAC=m
# CONFIG_CLK_RCAR_USB2_CLOCK_SEL is not set
CONFIG_EXTCON_USB_GPIO=y
CONFIG_EXTCON_USBC_CROS_EC=y
CONFIG_RESET_UNIPHIER_USB3=y
CONFIG_PHY_SUN4I_USB=y
# CONFIG_PHY_SUN9I_USB is not set
CONFIG_PHY_MESON8B_USB2=y
CONFIG_PHY_MESON_GXL_USB2=y
CONFIG_PHY_MESON_GXL_USB3=y
# CONFIG_BCM_KONA_USB2_PHY is not set
# CONFIG_PHY_BCM_NS_USB2 is not set
# CONFIG_PHY_BCM_NS_USB3 is not set
CONFIG_PHY_NS2_USB_DRD=y
CONFIG_PHY_BRCM_USB=y
CONFIG_PHY_HI6220_USB=y
CONFIG_PHY_HISI_INNO_USB2=y
# CONFIG_PHY_BERLIN_USB is not set
# CONFIG_PHY_PXA_28NM_USB2 is not set
# CONFIG_PHY_CPCAP_USB is not set
# CONFIG_PHY_QCOM_QUSB2 is not set
CONFIG_PHY_QCOM_USB_HS=y
# CONFIG_PHY_QCOM_USB_HSIC is not set
CONFIG_PHY_RCAR_GEN3_USB2=y
CONFIG_PHY_RCAR_GEN3_USB3=m
CONFIG_PHY_ROCKCHIP_INNO_USB2=y
# CONFIG_PHY_ROCKCHIP_USB is not set
CONFIG_PHY_TEGRA_XUSB=y
# CONFIG_PHY_TUSB1210 is not set


--
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: uas: add support for more quirk flags

2018-08-09 Thread Oliver Neukum
The hope that UAS devices would be less broken than old style storage
devices has turned out to be unfounded. Make UAS support more of the
quirk flags of the old driver.

Signed-off-by: Oliver Neukum 
---
 drivers/usb/storage/uas.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 9e9de5452860..1f7b401c4d04 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -842,6 +842,27 @@ static int uas_slave_configure(struct scsi_device *sdev)
sdev->skip_ms_page_8 = 1;
sdev->wce_default_on = 1;
}
+
+   /*
+* Some disks return the total number of blocks in response
+* to READ CAPACITY rather than the highest block number.
+* If this device makes that mistake, tell the sd driver.
+*/
+   if (devinfo->flags & US_FL_FIX_CAPACITY)
+   sdev->fix_capacity = 1;
+
+   /*
+* Some devices don't like MODE SENSE with page=0x3f,
+* which is the command used for checking if a device
+* is write-protected.  Now that we tell the sd driver
+* to do a 192-byte transfer with this command the
+* majority of devices work fine, but a few still can't
+* handle it.  The sd driver will simply assume those
+* devices are write-enabled.
+*/
+   if (devinfo->flags & US_FL_NO_WP_DETECT)
+   sdev->skip_ms_page_3f = 1;
+
scsi_change_queue_depth(sdev, devinfo->qdepth - 2);
return 0;
 }
-- 
2.16.4

--
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: Should usb_gadget_disconnect() call driver's ->disconnect?

2018-08-09 Thread Alan Stern
On Thu, 9 Aug 2018, Felipe Balbi wrote:

> 
> Hi,
> 
> Alan Stern  writes:
> >> Alan Stern  writes:
> >> > Felipe:
> >> >
> >> > The documentation doesn't state whether a gadget driver's 
> >> > ->disconnect() callback will be invoked when usb_gadget_disconnect() 
> >> > runs.  Probably the UDC drivers' behavior has changed over the years.
> >> >
> >> > In any case, it's likely that various UDC drivers do behave
> >> > differently.  My current feeling is that ->disconnect() should be
> >> > invoked only when Vbus turns off, but I can't guarantee that all UDCs 
> >> > will do this.
> >> 
> >> my feeling is that ->disconnect() should be called everytime we cause
> >> the session to be killed. VBUS Turning off is a guaratee that session is
> >> gone, but so is disconnecting data pullup, which is what
> >> usb_gadget_disconnect() does.
> >
> > Okay.  I don't mind either way, so long as it is settled.
> >
> >> > How do you feel about documenting this ambiguity as in the patch below?
> >> > If you think this is okay, I'll submit it formally.
> >> 
> >> Perhaps a better approach would be to start auditing all UDCs to make
> >> sure that ->disconnect() is called when pullup is disconnected. Then we
> >> can move ->disconnect() to usb_gadget_disconnect() itself. No?
> >
> > Rather the other way around: Call ->disconnect() from
> > usb_gadget_disconnect() itself, then audit all the UDCs to make sure
> > they don't invoke the callbackup.  That's better than adding a callback
> > to the UDCs that are missing it, only then to remove it from all of
> > them later on.
> 
> Fair enough. Do you want to handle this or would you prefer that I add
> to my list?

I'll send in a patch modifying usb_gadget_disconnect(), and I'll check 
up on dummy-hcd and net2280.  The rest I prefer to leave for you.  
Okay?

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


Re: [PATCH 1/2] usb storage: group dependent USB storage Kconfig entries together

2018-08-09 Thread Alan Stern
On Thu, 9 Aug 2018, Vladimir Zapolskiy wrote:

> Instead of explicit setting of USB_STORAGE dependency for every
> underlying build entries, exploit if USB_STORAGE / endif block.
> 
> Signed-off-by: Vladimir Zapolskiy 

I think this is a worthwhile cleanup, although to make Greg happy you 
should mention in the description that this shortens the Kconfig file, 
making it easier to read and less error-prone, with no changes in 
behavior.

> @@ -188,7 +177,6 @@ config USB_STORAGE_CYPRESS_ATACB
>  config USB_STORAGE_ENE_UB6250
>   tristate "USB ENE card reader support"
>   depends on SCSI
> - depends on USB_STORAGE

You can also remove the "depends on SCSI" line here, since USB_STORAGE
already depends on SCSI.

> @@ -202,7 +190,7 @@ config USB_STORAGE_ENE_UB6250
>  
>  config USB_UAS
>   tristate "USB Attached SCSI"
> - depends on SCSI && USB_STORAGE
> + depends on SCSI
>   help
> The USB Attached SCSI protocol is supported by some USB
> storage devices.  It permits higher performance by supporting

As Oliver points out, uas is significantly different from all the other 
entries in this file.  They are sub-drivers for usb-storage, whereas 
uas is an almost totally separate driver.  Yes, it does depend on 
usb-storage now, but that's subject to change in the future since the 
overlap between the two drivers is quite small.

Just put the UAS portion outside the new conditional region and keep
its explicit dependencies.

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


Re: broken TRIM support for JMS578 in uas mode

2018-08-09 Thread Oliver Neukum
On Mo, 2018-07-30 at 14:43 +0300, Mailing Lists wrote:
> I cannot issue TRIM commands to SSD behind a JMS578-based sata to
> usb-c adapter. Tried with Fedora 28 kernel and with latest
> 4.18.0-0.rc6.git0.1.vanilla.knurd.1.fc28.x86_64
> lsblk -D shows that discard is not enabled, but the SSD has this
> capability (see below)
> 
> However Windows 10 successfully TRIMs the device. Also the
> trimcheck.exe tool validates the TRIM operation. This makes me think
> the linux uas driver needs additional reverse engineering or support
> from Jmicron about this chipset.

Hi,

The VPD page for TRIM support should be 0xb0. Could you provide that?

If all else fails:
for each SCSI device (UAS devices internally are SCSI) there is a
"provisioning_mode" attribute in sysfs. You can try to force TRIM
to be used.

https://gist.github.com/cathay4t/e80e02a737242a5f3824606543631bfe

Strictly speaking this is a SCSI issue, not a UAS problem.

HTH
Oliver

--
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: Should usb_gadget_disconnect() call driver's ->disconnect?

2018-08-09 Thread Felipe Balbi

Hi,

Alan Stern  writes:
>> Alan Stern  writes:
>> > Felipe:
>> >
>> > The documentation doesn't state whether a gadget driver's 
>> > ->disconnect() callback will be invoked when usb_gadget_disconnect() 
>> > runs.  Probably the UDC drivers' behavior has changed over the years.
>> >
>> > In any case, it's likely that various UDC drivers do behave
>> > differently.  My current feeling is that ->disconnect() should be
>> > invoked only when Vbus turns off, but I can't guarantee that all UDCs 
>> > will do this.
>> 
>> my feeling is that ->disconnect() should be called everytime we cause
>> the session to be killed. VBUS Turning off is a guaratee that session is
>> gone, but so is disconnecting data pullup, which is what
>> usb_gadget_disconnect() does.
>
> Okay.  I don't mind either way, so long as it is settled.
>
>> > How do you feel about documenting this ambiguity as in the patch below?
>> > If you think this is okay, I'll submit it formally.
>> 
>> Perhaps a better approach would be to start auditing all UDCs to make
>> sure that ->disconnect() is called when pullup is disconnected. Then we
>> can move ->disconnect() to usb_gadget_disconnect() itself. No?
>
> Rather the other way around: Call ->disconnect() from
> usb_gadget_disconnect() itself, then audit all the UDCs to make sure
> they don't invoke the callbackup.  That's better than adding a callback
> to the UDCs that are missing it, only then to remove it from all of
> them later on.

Fair enough. Do you want to handle this or would you prefer that I add
to my list?

-- 
balbi


signature.asc
Description: PGP signature


Re: [PATCH] WORLDE Controller KS49 or Prodipe MIDI 49C USB controller

2018-08-09 Thread Maxence Duprès
Wonderful,

I'm happy to make a little contribution. I have so much to learn on Linux.

Thanks you!

Le 09/08/2018 à 11:28, Greg KH a écrit :
 > On Wed, Aug 08, 2018 at 11:56:33PM +, Maxence Duprès wrote:
 >> WORLDE Controller KS49 or Prodipe MIDI 49C USB controller
 >> cause a -EPROTO error, a communication restart and loop again.
 >>
 >> This issue has already been fixed for KS25.
 >> https://lore.kernel.org/patchwork/patch/753077/
 >>
 >> I just add device 201 for KS49 in quirks.c to get it works.
 >>
 >> This is the patch I propose.
 >>
 >> Signed-off-by: Laurent Roux 
 >> ---
 >>   drivers/usb/core/quirks.c | 1 --
 >>   1 file changed(-)
 >
 > THis was a bit corrupted, but I edited it by hand and applied it,
 > thanks!
 >
 > greg k-h




Re: [PATCH 2/2] usb storage: remove inherited SCSI dependency for USB_STORAGE subentries

2018-08-09 Thread Oliver Neukum
On Do, 2018-08-09 at 11:21 +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 09, 2018 at 09:38:40AM +0200, Oliver Neukum wrote:
> > On Do, 2018-08-09 at 01:01 +0300, Vladimir Zapolskiy wrote:
> > > Because USB_STORAGE build symbol strictly depends on SCSI build
> > > symbol, there is no need to specify it again for USB_UAS and
> > > USB_STORAGE_ENE_UB6250 build options.
> > 
> > [..]
> > 
> > >  config USB_UAS
> > >   tristate "USB Attached SCSI"
> > > - depends on SCSI
> > >   help
> > > The USB Attached SCSI protocol is supported by some USB
> > > storage devices.  It permits higher performance by supporting
> > 
> > Hi,
> > 
> > I am sorry, but this is wrong. You can build and use UAS without
> > old style storage support. I do not recommend that you do so,
> > but in theory it is possible.
> > And UAS very much depends on storage.
> 
> But today UAS depends on SCSI and USB_STORAGE, so if this is true, it's
> not very obvious :)

Hi,

yes, this is an issue. Nevertheless UAS depends on SCSI and this
dependency better stay.

Regards
Oliver

--
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] WORLDE Controller KS49 or Prodipe MIDI 49C USB controller

2018-08-09 Thread Greg KH
On Wed, Aug 08, 2018 at 11:56:33PM +, Maxence Duprès wrote:
> WORLDE Controller KS49 or Prodipe MIDI 49C USB controller
> cause a -EPROTO error, a communication restart and loop again.
> 
> This issue has already been fixed for KS25.
> https://lore.kernel.org/patchwork/patch/753077/
> 
> I just add device 201 for KS49 in quirks.c to get it works.
> 
> This is the patch I propose.
> 
> Signed-off-by: Laurent Roux 
> ---
>   drivers/usb/core/quirks.c | 1 --
>   1 file changed(-)

THis was a bit corrupted, but I edited it by hand and applied it,
thanks!

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: [PATCH 2/2] usb storage: remove inherited SCSI dependency for USB_STORAGE subentries

2018-08-09 Thread Greg Kroah-Hartman
On Thu, Aug 09, 2018 at 09:38:40AM +0200, Oliver Neukum wrote:
> On Do, 2018-08-09 at 01:01 +0300, Vladimir Zapolskiy wrote:
> > Because USB_STORAGE build symbol strictly depends on SCSI build
> > symbol, there is no need to specify it again for USB_UAS and
> > USB_STORAGE_ENE_UB6250 build options.
> 
> [..]
> 
> >  config USB_UAS
> > tristate "USB Attached SCSI"
> > -   depends on SCSI
> > help
> >   The USB Attached SCSI protocol is supported by some USB
> >   storage devices.  It permits higher performance by supporting
> 
> Hi,
> 
> I am sorry, but this is wrong. You can build and use UAS without
> old style storage support. I do not recommend that you do so,
> but in theory it is possible.
> And UAS very much depends on storage.

But today UAS depends on SCSI and USB_STORAGE, so if this is true, it's
not very obvious :)

thanks,

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: [PATCH 1/2] usb storage: group dependent USB storage Kconfig entries together

2018-08-09 Thread Greg Kroah-Hartman
On Thu, Aug 09, 2018 at 01:01:54AM +0300, Vladimir Zapolskiy wrote:
> Instead of explicit setting of USB_STORAGE dependency for every
> underlying build entries, exploit if USB_STORAGE / endif block.

Why change this?  What benifit does this provide?

thanks,

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: [PATCH 2/2] usb storage: remove inherited SCSI dependency for USB_STORAGE subentries

2018-08-09 Thread Oliver Neukum
On Do, 2018-08-09 at 10:50 +0300, Vladimir Zapolskiy wrote:
> Hi Oliver,
> 
> On 08/09/2018 10:38 AM, Oliver Neukum wrote:
> > On Do, 2018-08-09 at 01:01 +0300, Vladimir Zapolskiy wrote:
> > > Because USB_STORAGE build symbol strictly depends on SCSI build
> > > symbol, there is no need to specify it again for USB_UAS and
> > > USB_STORAGE_ENE_UB6250 build options.
> > 
> > [..]
> > 
> > >  config USB_UAS
> > >   tristate "USB Attached SCSI"
> > > - depends on SCSI
> > >   help
> > > The USB Attached SCSI protocol is supported by some USB
> > > storage devices.  It permits higher performance by supporting
> > 
> > Hi,
> > 
> > I am sorry, but this is wrong. You can build and use UAS without
> 
> can you please elaborate what is wrong exactly.
> 
> The change is non-functional.

Hi,

as far as I can tell you are introducing an implicit dependency
of CONFIG_USB_UAS on CONFIG_USB_STORAGE.
Now, firstly implicit references are bad anyway, secondly
in this case it is wrong. Uas works without usb-storage.

Regards
Oliver



--
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 storage: remove inherited SCSI dependency for USB_STORAGE subentries

2018-08-09 Thread Vladimir Zapolskiy
Hi Oliver,

On 08/09/2018 10:38 AM, Oliver Neukum wrote:
> On Do, 2018-08-09 at 01:01 +0300, Vladimir Zapolskiy wrote:
>> Because USB_STORAGE build symbol strictly depends on SCSI build
>> symbol, there is no need to specify it again for USB_UAS and
>> USB_STORAGE_ENE_UB6250 build options.
> 
> [..]
> 
>>  config USB_UAS
>>  tristate "USB Attached SCSI"
>> -depends on SCSI
>>  help
>>The USB Attached SCSI protocol is supported by some USB
>>storage devices.  It permits higher performance by supporting
> 
> Hi,
> 
> I am sorry, but this is wrong. You can build and use UAS without

can you please elaborate what is wrong exactly.

The change is non-functional.

--
Best wishes,
Vladimir

> old style storage support. I do not recommend that you do so,
> but in theory it is possible.
> And UAS very much depends on storage.
> 
>   Regards
>   Oliver
> 
> Nacked-by: Oliver Neukum 
> 

--
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 storage: remove inherited SCSI dependency for USB_STORAGE subentries

2018-08-09 Thread Oliver Neukum
On Do, 2018-08-09 at 01:01 +0300, Vladimir Zapolskiy wrote:
> Because USB_STORAGE build symbol strictly depends on SCSI build
> symbol, there is no need to specify it again for USB_UAS and
> USB_STORAGE_ENE_UB6250 build options.

[..]

>  config USB_UAS
>   tristate "USB Attached SCSI"
> - depends on SCSI
>   help
> The USB Attached SCSI protocol is supported by some USB
> storage devices.  It permits higher performance by supporting

Hi,

I am sorry, but this is wrong. You can build and use UAS without
old style storage support. I do not recommend that you do so,
but in theory it is possible.
And UAS very much depends on storage.

Regards
Oliver

Nacked-by: Oliver Neukum 
--
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