[PATCH 1/1] usb: gadget: udc: fix free_irq() after request_irq() failed
My static checker detected the mistake. I fix this by changing goto
err_irq to goto err_req. The label err_irq is not used now
so this patch also removes it.
Signed-off-by: Takeshi Yoshimura y...@sslab.ics.keio.ac.jp
---
drivers/usb/gadget/udc/fotg210-udc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/fotg210-udc.c
b/drivers/usb/gadget/udc/fotg210-udc.c
index e547ea7..1137e33 100644
--- a/drivers/usb/gadget/udc/fotg210-udc.c
+++ b/drivers/usb/gadget/udc/fotg210-udc.c
@@ -1171,7 +1171,7 @@ static int fotg210_udc_probe(struct platform_device *pdev)
udc_name, fotg210);
if (ret 0) {
pr_err(request_irq error (%d)\n, ret);
- goto err_irq;
+ goto err_req;
}
ret = usb_add_gadget_udc(pdev-dev, fotg210-gadget);
@@ -1183,7 +1183,6 @@ static int fotg210_udc_probe(struct platform_device *pdev)
return 0;
err_add_udc:
-err_irq:
free_irq(ires-start, fotg210);
err_req:
--
1.9.1
--
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 -next] usb: dwc3: Remove unprintable characters from Kconfig
Fix: drivers/usb/dwc3/Kconfig:16:warning: ignoring unsupported character '�' drivers/usb/dwc3/Kconfig:16:warning: ignoring unsupported character '�' Fixes: 88bc9d194ff6 (usb: dwc3: add ULPI interface support) Cc: Heikki Krogerus heikki.kroge...@linux.intel.com Signed-off-by: Guenter Roeck li...@roeck-us.net --- drivers/usb/dwc3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index 473bfaa96c30..dede32e809b6 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -13,7 +13,7 @@ if USB_DWC3 config USB_DWC3_ULPI bool Register ULPI PHY Interface - depends on USB_ULPI_BUS=y || USB_ULPI_BUS=USB_DWC3 + depends on USB_ULPI_BUS=y || USB_ULPI_BUS=USB_DWC3 help Select this if you have ULPI type PHY attached to your DWC3 controller. -- 2.1.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: questions about uas
So I did some further investigation on the weird optimal i/o size I got from my usb3/sata adapter/ssd, started by grep'ing the size in the /sys/block/sdx/queue: [tom@localhost ~]$ grep 33553920 /sys/block/sdb/queue/* grep: /sys/block/sdb/queue/iosched: Is a directory /sys/block/sdb/queue/optimal_io_size:33553920 /sys/block/sdb/queue/write_same_max_bytes:33553920 Because of this, for once I thought that optimal_io_size is somehow set to match with write_same_max_bytes, but later I proved that I was wrong, and it is just sort of a coincidence. However, I found out that the 33553920 of write_same_max_bytes is actually originated from a max_write_same_blocks: [tom@localhost ~]$ grep 65535 `find /sys/devices -name max_write_same_blocks` /sys/devices/pci:00/:00:14.0/usb4/4-2/4-2:1.0/host7/target7:0:0/7:0:0:0/scsi_disk/7:0:0:0/max_write_same_blocks:65535 which is set by: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5db44863b6ebbb400c5e61d56ebe8f21ef48b1bd but not my hardware: [tom@localhost ~]$ sudo sg_inq -p 0xb0 /dev/sdb | grep same Maximum write same length: 0x0 blocks [tom@localhost ~]$ sudo sg_write_same --10 --num=1 /dev/sdb Write same(10): Illegal request, invalid opcode While it is disabled through the variable no_write_same for usb-storage (similarly for ATA and FireWire), for some reason, the uas driver neither uses (everything of) scsiglue nor set the variable itself. After setting the variable in uas.c, I found that the optimal i/o size is still 33553920. So I keep digging. It's actually supplied by the hardware through something called VPD: http://people.redhat.com/msnitzer/docs/io-limits.txt But when I use `sg_inq` to look into different drives, I see that one of them supplied an (enormous) OPTIMAL TRANSFER LENGTH but it's not used to derive the optimal_io_size for it: [tom@localhost ~]$ sudo sg_inq -p 0xb0 /dev/sdc | grep Optimal transfer length: Optimal transfer length: 8388607 blocks [tom@localhost ~]$ cat /sys/block/sdc/queue/optimal_io_size 0 So I suspect something is missing in the uas driver again, and I am right, which is: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=09b6b51b0b6c1b9bb61815baf205e4d74c89ff04 the skip_vpd_pages variable makes sd_try_extended_inquiry() in drivers/scsi/sd.c return 0 for the test in sd_revalidate_disk(), which prevent sd_read_block_limits() and hence blk_queue_io_opt() from running. So finally I solve all the mystery I got and I would like to share a bit here. I hope it is alright. Also, should no_write_same and skip_vpd_pages actually be set for uas devices as well? -- 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
Fwd: [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan
Hmm. Oliver is marked as the maintainer of the USB CDC code, but
others have touched it more recently. So I'm just wildly adding people
to the cc to comment on this patch and maybe apply it.
Oliver/David/Ben/Bjørn?
Linus
-- Forwarded message --
From: xiaomao xiaomao0...@hotmail.com
Date: Sun, Jun 14, 2015 at 1:18 PM
Subject: [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan
Form: Qianni mamaqia...@huawei.com
Huawei devices is the gereric CDC_NCM devices, but not is WWAN
devices. In the patch, we deleted the code about tagging Huawei
devices as WWAN.
---
Signed-off-by:Qianni mamaqia...@huawei.com
--- linux-3.19/drivers/net/usb/cdc_ncm.c.orig 2015-06-15 01:29:52.354238079
+0800
+++ linux-3.19/drivers/net/usb/cdc_ncm.c2015-06-15 01:31:04.074236246
+0800
@@ -1573,12 +1573,12 @@ static const struct usb_device_id cdc_de
},
/* tag Huawei devices as wwan */
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1,
+ /*{ USB_VENDOR_AND_INTERFACE_INFO(0x12d1,
USB_CLASS_COMM,
USB_CDC_SUBCLASS_NCM,
USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)wwan_info,
- },
+ },*/
/* Infineon(now Intel) HSPA Modem platform */
{ USB_DEVICE_AND_INTERFACE_INFO(0x1519, 0x0443,
Re: [PATCH v5 2/7] phy-sun4i-usb: Add extcon support for the otg phy (phy0)
Hi Hans,
On Sat, Jun 13, 2015 at 9:37 PM, Hans de Goede hdego...@redhat.com wrote:
The sunxi musb glue needs to know if a host or normal usb cable is plugged
in, add extcon support so that the musb glue can monitor the host status.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v5:
-Split out of the Add id and vbus detection support commit
-Ported to the new extcon API queued for 4.2
---
drivers/phy/Kconfig | 1 +
drivers/phy/phy-sun4i-usb.c | 32 +++-
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a53bd5b..9841780 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -173,6 +173,7 @@ config PHY_SUN4I_USB
tristate Allwinner sunxi SoC USB PHY driver
depends on ARCH_SUNXI HAS_IOMEM OF
depends on RESET_CONTROLLER
+ depends on EXTCON
select GENERIC_PHY
help
Enable this to support the transceiver that is part of Allwinner
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index bdf63ad..86d9ce1 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -23,6 +23,7 @@
#include linux/clk.h
#include linux/err.h
+#include linux/extcon.h
#include linux/io.h
#include linux/interrupt.h
#include linux/kernel.h
@@ -99,6 +100,7 @@ struct sun4i_usb_phy_data {
int index;
} phys[MAX_PHYS];
/* phy0 / otg related variables */
+ struct extcon_dev *extcon;
bool phy0_init;
bool phy0_poll;
struct gpio_desc *id_det_gpio;
@@ -343,7 +345,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
work_struct *work)
struct sun4i_usb_phy_data *data =
container_of(work, struct sun4i_usb_phy_data, detect.work);
struct phy *phy0 = data-phys[0].phy;
- int id_det, vbus_det;
+ int id_det, vbus_det, id_notify = 0, vbus_notify = 0;
id_det = gpiod_get_value_cansleep(data-id_det_gpio);
vbus_det = gpiod_get_value_cansleep(data-vbus_det_gpio);
@@ -358,15 +360,24 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
work_struct *work)
if (id_det != data-id_det) {
sun4i_usb_phy0_set_id_detect(phy0, id_det);
data-id_det = id_det;
+ id_notify = 1;
}
if (vbus_det != data-vbus_det) {
sun4i_usb_phy0_set_vbus_detect(phy0, vbus_det);
data-vbus_det = vbus_det;
+ vbus_notify = 1;
}
mutex_unlock(phy0-mutex);
+ if (id_notify)
+ extcon_set_cable_state_(data-extcon, EXTCON_USB_HOST,
+ !id_det);
+
+ if (vbus_notify)
+ extcon_set_cable_state_(data-extcon, EXTCON_USB, vbus_det);
+
if (data-phy0_poll)
queue_delayed_work(system_wq, data-detect, POLL_TIME);
}
@@ -407,6 +418,12 @@ static int sun4i_usb_phy_remove(struct platform_device
*pdev)
return 0;
}
+static const unsigned int sun4i_usb_phy0_cable[] = {
+ EXTCON_USB,
+ EXTCON_USB_HOST,
+ EXTCON_NONE,
+};
+
static int sun4i_usb_phy_probe(struct platform_device *pdev)
{
struct sun4i_usb_phy_data *data;
@@ -466,6 +483,19 @@ static int sun4i_usb_phy_probe(struct platform_device
*pdev)
return -ENODEV;
}
+ if (data-id_det_gpio) {
+ data-extcon = devm_extcon_dev_allocate(dev,
+ sun4i_usb_phy0_cable);
+ if (IS_ERR(data-extcon))
+ return PTR_ERR(data-extcon);
+
+ ret = devm_extcon_dev_register(dev, data-extcon);
+ if (ret) {
+ dev_err(dev, failed to register extcon: %d\n, ret);
+ return ret;
+ }
+ }
+
for (i = 0; i data-num_phys; i++) {
struct sun4i_usb_phy *phy = data-phys + i;
char name[16];
Looks good to me about or extcon part.
Acked-by: Chanwoo Choi cw00.c...@samsung.com
Thanks,
Chanwoo Choi
--
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: phy: phy-mxs-usb: suspend to RAM causes NULL pointer dereference
Subject: usb: phy: phy-mxs-usb: suspend to RAM causes NULL pointer dereference Hi, triggering suspend to RAM via sysfs on a i.MX28 causes a NULL pointer dereference. This regression seems to be introduced with commit efdbd3a5d6e (usb: phy: mxs: do not set PWD.RXPWD1PT1 for low speed connection): root@duckbill:/sys/power# echo mem state [ 83.677575] PM: Syncing filesystems ... done. [ 83.872011] Freezing user space processes ... (elapsed 0.006 seconds) done. [ 83.886817] Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done. [ 83.909215] Unable to handle kernel NULL pointer dereference at virtual address 017c [ 83.917520] pgd = c6d88000 [ 83.920277] [017c] *pgd=46ed9831, *pte=, *ppte= [ 83.926795] Internal error: Oops: 17 [#1] ARM [ 83.931191] Modules linked in: [ 83.934306] CPU: 0 PID: 435 Comm: bash Not tainted 4.0.0-rc4-next-20150320-gb8f4f66-dirty #163 [ 83.942940] Hardware name: Freescale MXS (Device Tree) [ 83.948102] task: c4954d00 ti: c6d2 task.ti: c6d2 [ 83.953544] PC is at regmap_read+0x10/0x5c [ 83.957695] LR is at mxs_phy_get_vbus_status+0x40/0x58 [ 83.962865] pc : [c0350a10]lr : [c03d8ac4]psr: 6013 [ 83.962865] sp : c6d21d20 ip : 0080 fp : 0002 [ 83.974368] r10: c0340180 r9 : c07c15b0 r8 : 0002 [ 83.979615] r7 : c06c6ad4 r6 : r5 : 01c0 r4 : [ 83.986166] r3 : r2 : c6d21d34 r1 : 01c0 r0 : 01c0 [ 83.992718] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 83.999876] Control: 0005317f Table: 46d88000 DAC: 0015 [ 84.005644] Process bash (pid: 435, stack limit = 0xc6d20190) [ 84.011413] Stack: (0xc6d21d20 to 0xc6d22000) [ 84.015813] 1d20: c7833f10 0001 c03d8ac4 0002 c00601c8 1074 c03d8ca4 [ 84.024030] 1d40: c0537268 6013 c7a6bc10 c7aea010 c7a6bc10 1074 c06c6ad4 c03d924c [ 84.032245] 1d60: c7aea010 c03d93dc c7a6bc10 c0fcf05c c07e165c c03401ac c7a6bc10 c0348818 [ 84.040459] 1d80: c0051864 6013 c07c15d0 c7a6bc10 c0fcf05c c7a6bc10 [ 84.048674] 1da0: c0fcf05c c7a6bc44 0002 c07c1564 c03494d0 c07c1590 00536bb0 [ 84.056888] 1dc0: c7a6bc10 c0fcf05c c07c1564 c0349c14 c07e1684 [ 84.065102] 1de0: 8061885f 0013 8061885f 0013 c005dec4 0002 [ 84.073316] 1e00: c0f91cc0 0003 c0f91cc0 c07e1684 c069b6d8 c069b6fc c069b6fc c07e3d18 [ 84.081529] 1e20: c00599f8 0003 c07a275c 6013 0004 [ 84.089741] 1e40: 0001 c07e1684 [ 84.097956] 1e60: c07e1678 c069b6fc c6d2 c07e3d18 c005e178 c06e4fbc c6d21e9c [ 84.106168] 1e80: 0002 c053539c 0003 c07e1684 c069b6d8 c069b6fc [ 84.114383] 1ea0: c069b6fc c07e3d18 c005a358 0001 c07e1468 [ 84.122596] 1ec0: c0054efc c0165f00 6013 [ 84.130812] 1ee0: c6d8c5c0 0003 0003 c0f91cc4 0004 c6d2 c0696b14 c0058d1c [ 84.139027] 1f00: c6d15b80 0004 c6d8c5c0 c6d8c5c0 c6d15b8c c6d2 c6d21f88 c02c7b38 [ 84.147240] 1f20: c6d15b80 c0166da4 c6d15b80 01f8e408 0004 c0165f74 [ 84.155455] 1f40: 0004 c6c39120 0004 01f8e408 c6d21f88 c000f648 c010090c [ 84.163671] 1f60: c6e17da0 c6c39120 c6c39120 c6c39120 c6c39120 0004 01f8e408 c000f648 [ 84.171884] 1f80: c0100b10 b6ef5b40 0004 01f8e408 b6ef5b40 [ 84.180097] 1fa0: 0004 c000f460 0004 01f8e408 0001 01f8e408 0004 [ 84.188311] 1fc0: 0004 01f8e408 b6ef5b40 0004 0004 01f8e408 0004 [ 84.196525] 1fe0: bec9595c b6e2143c b6e7716c 6010 0001 [ 84.204762] [c0350a10] (regmap_read) from [c03d8ac4] (mxs_phy_get_vbus_status+0x40/0x58) [ 84.213258] [c03d8ac4] (mxs_phy_get_vbus_status) from [c03d8ca4] (mxs_phy_suspend+0x54/0x120) [ 84.222185] [c03d8ca4] (mxs_phy_suspend) from [c03d924c] (ci_controller_suspend+0x40/0x60) [ 84.230847] [c03d924c] (ci_controller_suspend) from [c03d93dc] (ci_suspend+0x7c/0xbc) [ 84.239081] [c03d93dc] (ci_suspend) from [c03401ac] (platform_pm_suspend+0x2c/0x54) [ 84.247145] [c03401ac] (platform_pm_suspend) from [c0348818] (dpm_run_callback+0x48/0x12c) [ 84.255809] [c0348818] (dpm_run_callback) from [c03494d0] (__device_suspend+0x12c/0x370) [ 84.264294] [c03494d0] (__device_suspend) from [c0349c14] (dpm_suspend+0x134/0x2fc) [ 84.272350] [c0349c14] (dpm_suspend) from [c00599f8] (suspend_devices_and_enter+0x8c/0x6e4) [ 84.281094] [c00599f8] (suspend_devices_and_enter) from [c005a358] (pm_suspend+0x308/0x434) [ 84.289836] [c005a358] (pm_suspend) from [c0058d1c] (state_store+0x80/0xcc) [
[PATCH V2 1/1] usb:serial:f81534 Add F81532/534 Driver
This driver is for Fintek F81532/F81534 USB to Serial Ports IC. Features: 1. F81534 is 1-to-4 F81532 is 1-to-2 serial ports IC 2. Support Baudrate from B50 to B150 (excluding B100). 3. The RTS signal can be transformed their behavior with configuration for transceiver (for RS232/RS485/RS422) (/sys/class/ttyUSBx/uart_mode) 4. There are 4x3 output-only GPIOs to control transceiver mode. It's can be controlled via sysfs (/sys/class/ttyUSBx/gpio) Changelog from v1: 1. v1 version submit to staging tree, but Greg KH advised me to cleanup source code re-submit it to correct subsystem 2. Remove all custom ioctl commands If had any question, Please send email to hpeter+linux_ker...@gmail.com peter_h...@fintek.com.tw Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com --- drivers/usb/serial/Kconfig | 10 + drivers/usb/serial/Makefile |1 + drivers/usb/serial/f81534.c | 3162 +++ 3 files changed, 3173 insertions(+) create mode 100644 drivers/usb/serial/f81534.c diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig index b7cf198..4bf3011 100644 --- a/drivers/usb/serial/Kconfig +++ b/drivers/usb/serial/Kconfig @@ -255,6 +255,16 @@ config USB_SERIAL_F81232 To compile this driver as a module, choose M here: the module will be called f81232. +config USB_SERIAL_F8153X + tristate USB Fintek F81532/534 Multi-Ports Serial Driver + help + Say Y here if you want to use the Fintek F81532/534 Multi-Ports + usb to serial adapter. + + To compile this driver as a module, choose M here: the + module will be called f81534. + + config USB_SERIAL_GARMIN tristate USB Garmin GPS driver help diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile index 349d9df..9e43b7b 100644 --- a/drivers/usb/serial/Makefile +++ b/drivers/usb/serial/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_USB_SERIAL_EDGEPORT) += io_edgeport.o obj-$(CONFIG_USB_SERIAL_EDGEPORT_TI) += io_ti.o obj-$(CONFIG_USB_SERIAL_EMPEG) += empeg.o obj-$(CONFIG_USB_SERIAL_F81232)+= f81232.o +obj-$(CONFIG_USB_SERIAL_F8153X)+= f81534.o obj-$(CONFIG_USB_SERIAL_FTDI_SIO) += ftdi_sio.o obj-$(CONFIG_USB_SERIAL_GARMIN)+= garmin_gps.o obj-$(CONFIG_USB_SERIAL_IPAQ) += ipaq.o diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c new file mode 100644 index 000..8c817ee --- /dev/null +++ b/drivers/usb/serial/f81534.c @@ -0,0 +1,3162 @@ +/* + * F81532/F81534 USB to Serial Ports Bridge + * + * F81532 = 2 Serial Ports + * F81534 = 4 Serial Ports + * + * Copyright (C) 2014 Tom Tsai (tom_t...@fintek.com.tw) + * + */ +#include asm/unaligned.h +#include linux/errno.h +#include linux/init.h +#include linux/slab.h +#include linux/tty.h +#include linux/tty_driver.h +#include linux/tty_flip.h +#include linux/module.h +#include linux/serial.h +#include linux/usb.h +#include linux/usb/serial.h +#include linux/serial_reg.h +#include linux/uaccess.h +#include linux/version.h +#include linux/workqueue.h +#include linux/kfifo.h +#include linux/fs.h +#include linux/mutex.h + +/* Serial Port register Address */ +#define SERIAL_BASE_ADDRESS0x1200 +#define RECEIVE_BUFFER_REGISTER(0x00 + SERIAL_BASE_ADDRESS) +#define TRANSMIT_HOLDING_REGISTER (0x00 + SERIAL_BASE_ADDRESS) +#define INTERRUPT_ENABLE_REGISTER (0x01 + SERIAL_BASE_ADDRESS) +#define INTERRUPT_IDENT_REGISTER (0x02 + SERIAL_BASE_ADDRESS) +#define FIFO_CONTROL_REGISTER (0x02 + SERIAL_BASE_ADDRESS) +#define LINE_CONTROL_REGISTER (0x03 + SERIAL_BASE_ADDRESS) +#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS) +#define LINE_STATUS_REGISTER (0x05 + SERIAL_BASE_ADDRESS) +#define MODEM_STATUS_REGISTER (0x06 + SERIAL_BASE_ADDRESS) +#define CLK_SEL_REGISTER (0x08 + SERIAL_BASE_ADDRESS) +#define CONFIG1_REGISTER (0x09 + SERIAL_BASE_ADDRESS) +#define SADDRESS_REGISTER (0x0a + SERIAL_BASE_ADDRESS) +#define SADEN_REGISTER (0x0b + SERIAL_BASE_ADDRESS) +#define DIVISOR_LATCH_LSB (0x00 + SERIAL_BASE_ADDRESS) +#define DIVISOR_LATCH_MSB (0x01 + SERIAL_BASE_ADDRESS) +#define SCRATCH_PAD_REGISTER (0x07 + SERIAL_BASE_ADDRESS) + +#define F81534_RESERVE_ADDRESS_START 0x3000 +#define F81534_RESERVE_SIZE8 + +#define F81534_CUSTOM_ADDRESS_START0x4000 +#define F81534_CUSTOM_TOTAL_SIZE 0x1000 + +#define F81534_CUSTOM_DATA_SIZE0x10 +#define F81534_CUSTOM_MAX_IDX \ + (F81534_CUSTOM_TOTAL_SIZE/F81534_CUSTOM_DATA_SIZE) +#define F81534_CUSTOM_NO_CUSTOM_DATA (-1) + +#define F81534_MAX_DATA_BLOCK 64 +#define F81534_BUSY_STATUS 0x03 +#define F81534_MAX_BUS_RETRY 2000 + +/* default urb timeout
Re: [PATCH v5 0/7] phy-sun4i-usb: Add OTG and newer SoC support
Hi, On Saturday 13 June 2015 06:07 PM, Hans de Goede wrote: Hi Kishon, Here is a patch series with all my oustanding phy-sun4i-usb changes pending for merging into 4.3. This includes the 5th iteration of the OTG support addition, now with the extcon provider support addition split-out into a new patch and ported to the extcon API changes which are queued up for 4.2 from : http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-next-v4.2 which already merged in GKH's char-misc branch for 4.2, this means that this series now depends on those changes. Other than that this is a resend of some of the other feature addition patches I recently send rebased on top of v5 of the OTG support. Please merge this series for 4.3. sure, will queue once -rc1 is tagged. Thanks Kishon -- 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 RESENT] phy: tusb1210: make better use of gpiod API
Hi,
On Friday 12 June 2015 11:21 PM, Uwe Kleine-König wrote:
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Furthermore there is devm_gpiod_get_optional which is designed to get
optional gpios.
Simplify driver accordingly. Furthermore this is one caller less that
stops us making the flags argument to gpiod_get*() mandatory.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
Hello,
[for the initial submission I forgot linux-usb on Cc, Felipe Balbi
requested a resend]
note I plan to make the flags parameter mandatory for 4.3. So unless
this change gets into 4.2, would it be ok to let it go in via the gpio
tree?
This looks like a cleanup patch so it might not get in 4.2
If there is a dependency it should be fine. If you can just post this patch
again before queuing this in your tree (for 4.3), I can see if there are
patches that might cause merge conflicts with your change.
Thanks
Kishon
Best regards
Uwe
drivers/phy/phy-tusb1210.c | 30 --
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/phy/phy-tusb1210.c b/drivers/phy/phy-tusb1210.c
index 07efdd318bdc..93dd45f2f26e 100644
--- a/drivers/phy/phy-tusb1210.c
+++ b/drivers/phy/phy-tusb1210.c
@@ -61,32 +61,26 @@ static struct phy_ops phy_ops = {
static int tusb1210_probe(struct ulpi *ulpi)
{
- struct gpio_desc *gpio;
struct tusb1210 *tusb;
u8 val, reg;
- int ret;
tusb = devm_kzalloc(ulpi-dev, sizeof(*tusb), GFP_KERNEL);
if (!tusb)
return -ENOMEM;
- gpio = devm_gpiod_get(ulpi-dev, reset);
- if (!IS_ERR(gpio)) {
- ret = gpiod_direction_output(gpio, 0);
- if (ret)
- return ret;
- gpiod_set_value_cansleep(gpio, 1);
- tusb-gpio_reset = gpio;
- }
+ tusb-gpio_reset = devm_gpiod_get_optional(ulpi-dev, reset,
+ GPIOD_OUT_LOW);
+ if (IS_ERR(tusb-gpio_reset))
+ return PTR_ERR(tusb-gpio_reset);
- gpio = devm_gpiod_get(ulpi-dev, cs);
- if (!IS_ERR(gpio)) {
- ret = gpiod_direction_output(gpio, 0);
- if (ret)
- return ret;
- gpiod_set_value_cansleep(gpio, 1);
- tusb-gpio_cs = gpio;
- }
+ gpiod_set_value_cansleep(tusb-gpio_reset, 1);
+
+ tusb-gpio_cs = devm_gpiod_get_optional(ulpi-dev, cs,
+ GPIOD_OUT_LOW);
+ if (IS_ERR(tusb-gpio_cs))
+ return PTR_ERR(tusb-gpio_cs);
+
+ gpiod_set_value_cansleep(tusb-gpio_cs, 1);
/*
* VENDOR_SPECIFIC2 register in TUSB1210 can be used for configuring eye
--
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 v3 1/1] usb: core: lpm: set lpm_capable for root hub device
Commit 25cd2882e2fc (usb/xhci: Change how we indicate a host supports
Link PM.) removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change was to avoid touching usb core
internal field, a.k.a. lpm_capable, and let usb core to set it by
checking U1 and U2 exit latency values in the descriptor.
Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately,
root hub is a special usb device as it has no parent. Hub_port_init()
will never be called for a root hub device. That means lpm_capable will
by no means be set for the root hub. As the result, lpm isn't functional
at all in Linux kernel.
This patch add the code to check and set lpm_capable when registering a
root hub device. It could be back-ported to kernels as old as v3.15,
that contains the Commit 25cd2882e2fc (usb/xhci: Change how we indicate
a host supports Link PM.).
Cc: sta...@vger.kernel.org # 3.15
Reported-by: Kevin Strasser kevin.stras...@linux.intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/core/hcd.c | 7 +--
drivers/usb/core/hub.c | 2 +-
drivers/usb/core/usb.h | 1 +
3 files changed, 7 insertions(+), 3 deletions(-)
v1-v2 change log:
1. two code blocks merged
2. fix build error when CONFIG_PM is not set
v2-v3 change log:
1. further fix of build error when CONFIG_PM is not set
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 45a915c..1c1385e 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1022,9 +1022,12 @@ static int register_root_hub(struct usb_hcd *hcd)
dev_name(usb_dev-dev), retval);
return (retval 0) ? retval : -EMSGSIZE;
}
- if (usb_dev-speed == USB_SPEED_SUPER) {
+
+ if (le16_to_cpu(usb_dev-descriptor.bcdUSB) = 0x0201) {
retval = usb_get_bos_descriptor(usb_dev);
- if (retval 0) {
+ if (!retval) {
+ usb_dev-lpm_capable = usb_device_supports_lpm(usb_dev);
+ } else if (usb_dev-speed == USB_SPEED_SUPER) {
mutex_unlock(usb_bus_list_lock);
dev_dbg(parent_dev, can't read %s bos descriptor %d\n,
dev_name(usb_dev-dev), retval);
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 3b71516..884d702 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -122,7 +122,7 @@ struct usb_hub *usb_hub_to_struct_hub(struct usb_device
*hdev)
return usb_get_intfdata(hdev-actconfig-interface[0]);
}
-static int usb_device_supports_lpm(struct usb_device *udev)
+int usb_device_supports_lpm(struct usb_device *udev)
{
/* USB 2.1 (and greater) devices indicate LPM support through
* their USB 2.0 Extended Capabilities BOS descriptor.
diff --git a/drivers/usb/core/usb.h b/drivers/usb/core/usb.h
index 7eb1e26..457255a 100644
--- a/drivers/usb/core/usb.h
+++ b/drivers/usb/core/usb.h
@@ -65,6 +65,7 @@ extern int usb_hub_init(void);
extern void usb_hub_cleanup(void);
extern int usb_major_init(void);
extern void usb_major_cleanup(void);
+extern int usb_device_supports_lpm(struct usb_device *udev);
#ifdef CONFIG_PM
--
2.1.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: [Xen-devel] [Patch V2 2/3] usb: Introduce Xen pvUSB frontend
On 06/12/2015 06:20 PM, Greg KH wrote:
On Fri, Jun 12, 2015 at 04:10:00PM +0200, Juergen Gross wrote:
Introduces the Xen pvUSB frontend. With pvUSB it is possible for a Xen
domU to communicate with a USB device assigned to that domU. The
communication is all done via the pvUSB backend in a driver domain
(usually Dom0) which is owner of the physical device.
The code is taken from the pvUSB implementation in Xen done by Fujitsu
based on Linux kernel 2.6.18.
Changes from the original version are:
- port to upstream kernel
- put all code in just one source file
- move module to appropriate location in kernel tree
- adapt to Linux style guide
- minor code modifications to increase readability
Signed-off-by: Juergen Gross jgr...@suse.com
---
drivers/usb/Kconfig|2 +
drivers/usb/Makefile |2 +
drivers/usb/xen/Kconfig| 10 +
drivers/usb/xen/Makefile |5 +
drivers/usb/xen/xen-usbfront.c | 1647
A subdirectory for a single file? That seems like overkill, don't you
think? As this is a USB host driver, why not put it in that
directory?
As already suggested by David: I'll change this.
Also, last time these patches were posted, people asked why you can't
use libusb/usbfs instead, what happened with that? Or usbip?
Like David already said: this was the backend, which I'm currently
working on to be part of qemu using libusb.
+config XEN_USB_FRONTEND
+ tristate Xen USB frontend driver
+ depends on XEN
+ default m
Remove this, default should be 'n'.
Really? Don't you think default should be to use USB devices in Xen
guests? Kernels configured not to be able to run as Xen guests with
pv drivers won't have that module due to depends on XEN.
+/* status of attached device */
+struct vdevice_status {
+ int devnum;
+ enum usb_device_state status;
+enum usb_device_speed speed;
+};
Always run your patches through checkpatch.pl so people don't tell you
about the things that checkpatch.pl would have told you about...
I did (I'll change the indentation, of course):
./scripts/checkpatch.pl
jg/out.pvusb.v2/0002-usb-Introduce-Xen-pvUSB-frontend.patch
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#57:
new file mode 100644
total: 0 errors, 1 warnings, 1675 lines checked
jg/out.pvusb.v2/0002-usb-Introduce-Xen-pvUSB-frontend.patch has style
problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Juergen
--
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] phy: phy-mxs-usb: suspend to RAM causes NULL pointer dereference
Triggering suspend to RAM via sysfs on a i.MX28 causes a NULL pointer
dereference. This patch avoids the oops in mxs_phy_get_vbus_status()
by aborting since there is no syscon available.
Signed-off-by: Stefan Wahren stefan.wah...@i2se.com
Fixes: efdbd3a5d6e (usb: phy: mxs: do not set PWD.RXPWD1PT1 for low speed
connection)
CC: sta...@vger.kernel.org # 4.0
Acked-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/phy/phy-mxs-usb.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 8f7cb06..3fcc048 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -217,6 +217,9 @@ static bool mxs_phy_get_vbus_status(struct mxs_phy *mxs_phy)
{
unsigned int vbus_value;
+ if (!mxs_phy-regmap_anatop)
+ return false;
+
if (mxs_phy-port_id == 0)
regmap_read(mxs_phy-regmap_anatop,
ANADIG_USB1_VBUS_DET_STAT,
--
1.7.9.5
--
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/1] usb: core: lpm: set lpm_capable for root hub device
On 06/13/2015 11:00 PM, Alan Stern wrote:
On Sat, 13 Jun 2015, Lu Baolu wrote:
Commit 25cd2882e2fc (usb/xhci: Change how we indicate a host supports
Link PM.) removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change was to avoid touching usb core
internal field, a.k.a. lpm_capable, and let usb core to set it by
checking U1 and U2 exit latency values in the descriptor.
Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately,
root hub is a special usb device as it has no parent. Hub_port_init()
will never be called for a root hub device. That means lpm_capable will
by no means be set for the root hub. As the result, lpm isn't functional
at all in Linux kernel.
This patch add the code to check and set lpm_capable when registering a
root hub device. It could be back-ported to kernels as old as v3.15,
that contains the Commit 25cd2882e2fc (usb/xhci: Change how we indicate
a host supports Link PM.).
Cc: sta...@vger.kernel.org # 3.15
Reported-by: Kevin Strasser kevin.stras...@linux.intel.com
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
--- a/drivers/usb/core/usb.h
+++ b/drivers/usb/core/usb.h
@@ -82,6 +82,7 @@ extern int usb_runtime_suspend(struct device *dev);
extern int usb_runtime_resume(struct device *dev);
extern int usb_runtime_idle(struct device *dev);
extern int usb_set_usb2_hardware_lpm(struct usb_device *udev, int enable);
+extern int usb_device_supports_lpm(struct usb_device *udev);
#else
@@ -106,6 +107,11 @@ static inline int usb_set_usb2_hardware_lpm(struct usb_device *udev, int enable)
return 0;
}
+static inline int usb_device_supports_lpm(struct usb_device *udev)
+{
+ return 0;
+}
+
#endif
extern struct bus_type usb_bus_type;
In fact, usb_device_supports_lpm() is compiled even when CONFIG_PM
isn't set. Maybe this should be changed. But if you don't want to
change it now, you need to put the declaration outside the #ifdef
CONFIG_PM region. As it is, your patch is still broken (did you try
building it with CONFIG_PM unset?).
I am sorry for this silly mistake. I will move it out of CONFIG_PM region.
I tried building with CONFIG_PM unset. But it turns out that CONFIG_PM
was auto selected by some other items. I will test my next version of
patch with CONFIG_PM *really* unset before sending it out.
Thanks,
Baolu
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 V2 1/3] usb: Add Xen pvUSB protocol description
On 06/12/2015 06:23 PM, Greg KH wrote:
On Fri, Jun 12, 2015 at 04:09:59PM +0200, Juergen Gross wrote:
+enum usb_spec_version {
+ USB_VER_UNKNOWN = 0,
+ USB_VER_USB11,
+ USB_VER_USB20,
+ USB_VER_USB30, /* not supported yet */
+};
+
You are defining a bunch of things in this .h file that start with
usb yet are not part of the USB core at all, but rather are xen
specific. Please don't polute the namespace with such things.
Okay.
+/*
+ * USB pipe in usbif_request
+ *
+ * - port number: bits 0-4
+ * (USB_MAXCHILDREN is 31)
+ *
+ * - operation flag: bit 5
+ * (0 = submit urb,
+ * 1 = unlink urb)
+ *
+ * - direction: bit 7
+ * (0 = Host-to-Device [Out]
+ * 1 = Device-to-Host [In])
+ *
+ * - device address: bits 8-14
+ *
+ * - endpoint:bits 15-18
+ *
+ * - pipe type: bits 30-31
+ * (00 = isochronous, 01 = interrupt,
+ * 10 = control, 11 = bulk)
+ */
+
+#define USBIF_PIPE_PORT_MASK 0x001f
+#define USBIF_PIPE_UNLINK 0x0020
+#define USBIF_PIPE_DIR 0x0080
+#define USBIF_PIPE_DEV_MASK0x007f
+#define USBIF_PIPE_DEV_SHIFT 8
+#define USBIF_PIPE_EP_MASK 0x000f
+#define USBIF_PIPE_EP_SHIFT15
+#define USBIF_PIPE_TYPE_MASK 0x0003
+#define USBIF_PIPE_TYPE_SHIFT 30
+#define USBIF_PIPE_TYPE_ISOC 0
+#define USBIF_PIPE_TYPE_INT1
+#define USBIF_PIPE_TYPE_CTRL 2
+#define USBIF_PIPE_TYPE_BULK 3
Why can't you just use the defines we have for this already?
This interface is a stable ABI to be used outside of Linux by other
Xen guests as well. As long as those Linux internal definitions are
not guaranteed to remain unchanged forever, I'd rather have my own
defines.
+
+#define usbif_pipeportnum(pipe)((pipe)
USBIF_PIPE_PORT_MASK)
+#define usbif_setportnum_pipe(pipe, portnum) ((pipe) | (portnum))
+
+#define usbif_pipeunlink(pipe) ((pipe) USBIF_PIPE_UNLINK)
+#define usbif_pipesubmit(pipe) (!usbif_pipeunlink(pipe))
+#define usbif_setunlink_pipe(pipe) ((pipe) | USBIF_PIPE_UNLINK)
+
+#define usbif_pipein(pipe) ((pipe) USBIF_PIPE_DIR)
+#define usbif_pipeout(pipe)(!usbif_pipein(pipe))
+
+#define usbif_pipedevice(pipe) \
+ (((pipe) USBIF_PIPE_DEV_SHIFT) USBIF_PIPE_DEV_MASK)
+
+#define usbif_pipeendpoint(pipe) \
+ (((pipe) USBIF_PIPE_EP_SHIFT) USBIF_PIPE_EP_MASK)
+
+#define usbif_pipetype(pipe) \
+ (((pipe) USBIF_PIPE_TYPE_SHIFT) USBIF_PIPE_TYPE_MASK)
+#define usbif_pipeisoc(pipe) (usbif_pipetype(pipe) == USBIF_PIPE_TYPE_ISOC)
+#define usbif_pipeint(pipe)(usbif_pipetype(pipe) == USBIF_PIPE_TYPE_INT)
+#define usbif_pipectrl(pipe) (usbif_pipetype(pipe) == USBIF_PIPE_TYPE_CTRL)
+#define usbif_pipebulk(pipe) (usbif_pipetype(pipe) == USBIF_PIPE_TYPE_BULK)
Same for all of these?
Correct. :-)
+
+#define USBIF_MAX_SEGMENTS_PER_REQUEST (16)
+#define USBIF_MAX_PORTNR 31
Why does userspace have to know this?
Not userspace, but Xen guests. The number of segments per request and
the maximum port number are part of the interface between frontend and
backend, so they are defined here.
+
+/*
+ * RING for transferring urbs.
+ */
+struct usbif_request_segment {
+ grant_ref_t gref;
+ uint16_t offset;
+ uint16_t length;
+};
Please use proper kernel types for things that go outside of the kernel
(__u16 and the like). There is no uint16_t as a valid type in the
kernel, sorry. Well, ok, we have it, just because it snuck in somehow,
but it should be removed one of these days...
Okay.
+struct usbif_urb_request {
Again, very generic structure name for a xen specific thing :(
I'll change all names to use xenusb_ instead of usbif_ as prefix.
Juergen
--
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
TRIM/DISCARD for usb drives?
I have a SanDisk Extreme USB Flash Drive
(http://www.sandisk.com/products/usb/drives/extreme/), which does NOT
support UASP so is running under usb-storage.
According to `hdparm`, it seems to supports TRIM; and according to
`sg3_opcodes`, it seems to support ATA Pass-Through (12/16). However,
all TRIM/DISCARD related ioctl doesn't work with it at all.
So my question is, is TRIM/DISCARD possible at all in linux for usb
drives? If so, what are the requirements? If not, is it just not
implemented yet or an inherit problem of usb which cannot be fixed?
P.S. Although there's an SG_IO error, ATA Secure Erase seems to works
according to hexdump, and the drive is NOT bricked after many trials.
[tom@localhost ~]$ sudo blkdiscard /dev/sdc
blkdiscard: /dev/sdc: BLKDISCARD ioctl failed: Operation not supported
[tom@localhost ~]$ sudo blkdiscard -s /dev/sdc
blkdiscard: /dev/sdc: BLKSECDISCARD ioctl failed: Operation not supported
[tom@localhost ~]$ sudo mount /dev/sdc1 /mnt/
[tom@localhost ~]$ sudo fstrim /mnt/
fstrim: /mnt/: the discard operation is not supported
[tom@localhost ~]$ sudo hdparm -I /dev/sdc
/dev/sdc:
ATA device, with non-removable media
Model Number: SanDisk pSSD
Serial Number: 0a1e4434c
Firmware Revision: 3
Transport: Serial, ATA8-AST, SATA Rev 2.6
Standards:
Used: ATA-8-ACS revision 2d
Supported: 8 7 6 5
Configuration:
Logicalmaxcurrent
cylinders1638316383
heads1616
sectors/track6363
--
CHS current addressable sectors: 16514064
LBAuser addressable sectors: 61282631
LBA48 user addressable sectors: 61282631
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
device size with M = 1024*1024: 29923 MBytes
device size with M = 1000*1000: 31376 MBytes (31 GB)
cache/buffer size = unknown
Form Factor: 1.8 inch
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 1Current = 1
Advanced power management level: disabled
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
EnabledSupported:
*SMART feature set
Security Mode feature set
*Power Management feature set
Write cache
Look-ahead
*Host Protected Area feature set
*WRITE_BUFFER command
*READ_BUFFER command
*NOP cmd
*DOWNLOAD_MICROCODE
Advanced Power Management feature set
*48-bit Address feature set
*Device Configuration Overlay feature set
*Mandatory FLUSH_CACHE
*FLUSH_CACHE_EXT
*SMART error logging
*SMART self-test
*General Purpose Logging feature set
*WRITE_{DMA|MULTIPLE}_FUA_EXT
*64-bit World wide name
*WRITE_UNCORRECTABLE_EXT command
*Segmented DOWNLOAD_MICROCODE
*Gen1 signaling speed (1.5Gb/s)
*Gen2 signaling speed (3.0Gb/s)
*Gen3 signaling speed (6.0Gb/s)
*Native Command Queueing (NCQ)
*Software settings preservation
*DEVICE CONFIGURATION SET/IDENTIFY DMA commands
*Data Set Management TRIM supported (limit 8 blocks)
*Deterministic read ZEROs after TRIM
Security:
Master password revision code = 65534
supported
notenabled
notlocked
notfrozen
notexpired: security count
notsupported: enhanced erase
2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5001b400e4a14c43
NAA: 5
IEEE OUI: 001b40
Unique ID: 0e4a14c43
Checksum: correct
[tom@localhost ~]$ sudo sg_opcodes /dev/sdc
SanDisk Extreme 0001
Peripheral device type: disk
Opcode ServiceCDBName
(hex) action(h) size
---
00 6Test Unit Ready
03 6Request Sense
04 6Format Unit
08 6Read(6)
0a 6Write(6)
12 6Inquiry
15 6Mode select(6)
1a 6Mode sense(6)
1b 6Start stop unit
1d 6Send diagnostic
1e 6Prevent allow medium removal
23 10Read Format capacities
25 10Read capacity(10)
28 10Read(10)
2a 10Write(10)
2f 10Verify(10)
35 10
