Re: [PATCH 2/2] usb: gadget: f_uvc: Move to video_ioctl2
On Mon, Aug 18, 2014 at 11:16:36PM +0200, Laurent Pinchart wrote: > Hi Hans, > > On Monday 18 August 2014 18:24:26 Hans Verkuil wrote: > > On 08/18/2014 05:06 PM, Laurent Pinchart wrote: > > > Simplify ioctl handling by using video_ioctl2. > > > > Are you able to test this on actual hardware? And if so, can you run > > v4l2-compliance? > > I'm afraid not. I don't have a platform with an up and running USB peripheral > controller at the moment. You could test it with dummy_hcd gadget on an virtual or non usb machine. Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: serial: add Novatel Wireless GPS driver
On Tue, Aug 19, 2014 at 02:21:25PM -0600, Kirk Madsen wrote: > I applied your two patches to current Fedora core 20 kernel sources, > built, remembered to remove the work-around boot-params and run > grub2-mkconfig, and rebooted. My Novatel GPS is recognized on plug-in > to my USB2 ports and appears to work correctly. Great, thanks for testing. > Thank you. > > If you want more detail than "it appears to work" just ask. Could you just confirm that the device was bound to new driver by taking a look at dmesg. It should read something like: [ 77.106964] usb_serial_simple 1-2.4:1.0: novatel_gps converter detected [ 77.113403] usb 1-2.4: novatel_gps converter now attached to ttyUSB0 [ 77.117218] usb 1-2.4: novatel_gps converter now attached to ttyUSB1 [ 77.119812] usb 1-2.4: novatel_gps converter now attached to ttyUSB2 when you plug the device in. Also, did you verify all three ports? Thanks, Johan -- 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 net-next 0/4] r8152: firmware support
Parsing, checking, and writing the firmware. Hayes Wang (4): r8152: check code with checkpatch.pl r8152: replace strncpy with strlcpy r8152: remove clear_bp function r8152: support firmware files drivers/net/usb/r8152.c | 961 +--- 1 file changed, 903 insertions(+), 58 deletions(-) -- 1.9.3 -- 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 net-next 3/4] r8152: remove clear_bp function
The functions are used to update the firmware. Move the actions into
the firmware files.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 24
1 file changed, 24 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 33dcc97..937d132 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2189,28 +2189,6 @@ static void rtl_phy_reset(struct r8152 *tp)
}
}
-static void rtl_clear_bp(struct r8152 *tp)
-{
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_0, 0);
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_2, 0);
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_4, 0);
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_6, 0);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_0, 0);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_2, 0);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_4, 0);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_6, 0);
- mdelay(3);
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_BP_BA, 0);
- ocp_write_word(tp, MCU_TYPE_USB, USB_BP_BA, 0);
-}
-
-static void r8153_clear_bp(struct r8152 *tp)
-{
- ocp_write_byte(tp, MCU_TYPE_PLA, PLA_BP_EN, 0);
- ocp_write_byte(tp, MCU_TYPE_USB, USB_BP_EN, 0);
- rtl_clear_bp(tp);
-}
-
static void r8153_teredo_off(struct r8152 *tp)
{
u32 ocp_data;
@@ -2248,7 +2226,6 @@ static void r8152b_hw_phy_cfg(struct r8152 *tp)
r8152b_disable_aldps(tp);
- rtl_clear_bp(tp);
r8152b_enable_aldps(tp);
set_bit(PHY_RESET, &tp->flags);
@@ -2404,7 +2381,6 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
r8152_mdio_write(tp, MII_BMCR, data);
}
- r8153_clear_bp(tp);
if (tp->version == RTL_VER_03) {
data = ocp_reg_read(tp, OCP_EEE_CFG);
--
1.9.3
--
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 net-next 2/4] r8152: replace strncpy with strlcpy
Replace the strncpy with strlcpy, and use sizeof to determine the
length.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2470d9c..33dcc97 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3151,8 +3151,8 @@ static void rtl8152_get_drvinfo(struct net_device *netdev,
{
struct r8152 *tp = netdev_priv(netdev);
- strncpy(info->driver, MODULENAME, ETHTOOL_BUSINFO_LEN);
- strncpy(info->version, DRIVER_VERSION, ETHTOOL_BUSINFO_LEN);
+ strlcpy(info->driver, MODULENAME, sizeof(info->driver));
+ strlcpy(info->version, DRIVER_VERSION, sizeof(info->version));
usb_make_path(tp->udev, info->bus_info, sizeof(info->bus_info));
}
--
1.9.3
--
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 net-next 4/4] r8152: support firmware files
The firmware file is composed of the fw header and the commands. Each
command has the following type.
cmd(2 bytes) + length(2 bytes) + data(variable bytes)
Before applying the firmware, the driver would check the fw header and
each command.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 867 +++-
1 file changed, 866 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 937d132..63542cc 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -21,10 +21,11 @@
#include
#include
#include
+#include
#include
/* Version Information */
-#define DRIVER_VERSION "v1.06.0 (2014/03/03)"
+#define DRIVER_VERSION "v1.07.0 (2014/08/20)"
#define DRIVER_AUTHOR "Realtek linux nic maintainers "
#define DRIVER_DESC "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters"
#define MODULENAME "r8152"
@@ -577,6 +578,16 @@ struct r8152 {
void (*unload)(struct r8152 *);
} rtl_ops;
+ struct rtl_fw {
+ const struct firmware *fw;
+
+#define RTL_VER_SIZE 32
+
+ char version[RTL_VER_SIZE];
+ u8 *code;
+ size_t code_size;
+ } rtl_fw;
+
int intr_interval;
u32 saved_wolopts;
u32 msg_enable;
@@ -1321,6 +1332,852 @@ err1:
return -ENOMEM;
}
+#define FW_SIGNATURE 0x0bda8152
+
+enum fw_cmd {
+ FW_CMD_INVALID = 0,
+
+ FW_CMD_GENERIC_WRITE,
+ FW_CMD_WRITE_BYTE,
+ FW_CMD_WRITE_WORD,
+ FW_CMD_WRITE_DWORD,
+ FW_CMD_READ_BYTE,
+ FW_CMD_READ_WORD,
+ FW_CMD_READ_DWORD,
+ FW_CMD_W0W1_BYTE,
+ FW_CMD_W0W1_WORD,
+ FW_CMD_W0W1_DWORD,
+ FW_CMD_W0W1_CURRENT,
+ FW_CMD_WRITE_CURRENT_BYTE,
+ FW_CMD_WRITE_CURRENT_WORD,
+ FW_CMD_WRITE_CURRENT_DWORD,
+ FW_CMD_CMP,
+ FW_CMD_JMP,
+ FW_CMD_JE,
+ FW_CMD_JNE,
+ FW_CMD_JA,
+ FW_CMD_JAE,
+ FW_CMD_JB,
+ FW_CMD_JBE,
+ FW_CMD_CX,
+ FW_CMD_LOOP,
+ FW_CMD_LOOPE,
+ FW_CMD_LOOPNE,
+ FW_CMD_USLEEP,
+
+ FW_CMD_END,
+ FW_CMD_MAX
+};
+
+struct fw_cmd_generic {
+ __le16 cmd;
+ __le16 length;
+} __packed;
+
+struct fw_cmd_most_used {
+ __le16 type;
+ __le16 addr;
+} __packed;
+
+struct fw_header {
+ __le32 signature;
+ charversion[RTL_VER_SIZE];
+ __le32 fw_start;
+ __le32 fw_len;
+} __packed;
+
+static bool rtl_fw_format_ok(struct rtl_fw *rtl_fw)
+{
+ const struct firmware *fw = rtl_fw->fw;
+ struct fw_header *fw_header = (struct fw_header *)fw->data;
+ char *version = rtl_fw->version;
+ size_t i, size, start;
+ u8 checksum = 0;
+ bool rc = false;
+
+ if (fw->size < sizeof(*fw_header))
+ goto out;
+
+ if (__le32_to_cpu(fw_header->signature) != FW_SIGNATURE)
+ goto out;
+
+ start = le32_to_cpu(fw_header->fw_start);
+ if (start > fw->size)
+ goto out;
+
+ size = le32_to_cpu(fw_header->fw_len);
+ if (size > (fw->size - start))
+ goto out;
+
+ for (i = 0; i < fw->size; i++)
+ checksum += fw->data[i];
+ if (checksum != 0)
+ goto out;
+
+ memcpy(version, fw_header->version, RTL_VER_SIZE);
+
+ rtl_fw->code = (u8 *)(fw->data + start);
+ rtl_fw->code_size = size;
+
+ version[RTL_VER_SIZE - 1] = 0;
+
+ rc = true;
+out:
+ return rc;
+}
+
+static void rtl_fw_get_info2(u8 *d2, u16 *ptype, u16 *paddr)
+{
+ struct fw_cmd_most_used info2;
+
+ memcpy(&info2, d2, sizeof(info2));
+ *ptype = __le16_to_cpu(info2.type);
+ *paddr = __le16_to_cpu(info2.addr);
+}
+
+static bool rtl_fw_data_ok(u8 *d, size_t total)
+{
+ u16 cmd, len, type, addr, byteen, size, cx = 0;
+ struct fw_cmd_generic op;
+ bool result = false;
+ __le16 le16_data;
+ __le32 le32_data;
+ size_t i = 0, j;
+
+ while (i < total) {
+ if (i + sizeof(op) > total)
+ goto result_return;
+
+ memcpy(&op, &d[i], sizeof(op));
+ cmd = __le16_to_cpu(op.cmd);
+ len = __le16_to_cpu(op.length);
+ j = i + sizeof(op);
+
+ switch (cmd) {
+ case FW_CMD_GENERIC_WRITE:
+ /* struct fw_cmd_generic_write {
+* struct fw_cmd_generic op;
+* struct fw_cmd_most_used info2;
+* __le16 data_length;
+* };
+*/
+
+ if ((j + sizeof(struct fw_cmd_most_used)) > total)
+ goto result_return;
+
+ rtl_fw_get_info2(&d[j], &type, &addr);
+ j += sizeof(struct fw_cmd_most_used);
+
+
[PATCH net-next 1/4] r8152: check code with checkpatch.pl
626: CHECK: Alignment should match open parenthesis
646: CHECK: Alignment should match open parenthesis
655: CHECK: Alignment should match open parenthesis
695: CHECK: Alignment should match open parenthesis
729: CHECK: Alignment should match open parenthesis
739: CHECK: Alignment should match open parenthesis
976: WARNING: externs should be avoided in .c files
1314: CHECK: Alignment should match open parenthesis
1358: WARNING: networking block comments don't use an empty /* line, use /*
Comment...
1402: WARNING: networking block comments don't use an empty /* line, use /*
Comment...
1521: CHECK: multiple assignments should be avoided
1775: CHECK: Alignment should match open parenthesis
1838: CHECK: multiple assignments should be avoided
1843: CHECK: multiple assignments should be avoided
1847: CHECK: multiple assignments should be avoided
1850: WARNING: Missing a blank line after declarations
1864: CHECK: Alignment should match open parenthesis
1872: CHECK: braces {} should be used on all arms of this statement
1906: CHECK: usleep_range is preferred over udelay
2865: WARNING: networking block comments don't use an empty /* line, use /*
Comment...
3088: CHECK: Alignment should match open parenthesis
total: 0 errors, 5 warnings, 16 checks, 3567 lines checked
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 66 ++---
1 file changed, 35 insertions(+), 31 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 87f7104..2470d9c 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -623,8 +623,8 @@ int get_registers(struct r8152 *tp, u16 value, u16 index,
u16 size, void *data)
return -ENOMEM;
ret = usb_control_msg(tp->udev, usb_rcvctrlpipe(tp->udev, 0),
- RTL8152_REQ_GET_REGS, RTL8152_REQT_READ,
- value, index, tmp, size, 500);
+ RTL8152_REQ_GET_REGS, RTL8152_REQT_READ,
+ value, index, tmp, size, 500);
memcpy(data, tmp, size);
kfree(tmp);
@@ -643,8 +643,8 @@ int set_registers(struct r8152 *tp, u16 value, u16 index,
u16 size, void *data)
return -ENOMEM;
ret = usb_control_msg(tp->udev, usb_sndctrlpipe(tp->udev, 0),
- RTL8152_REQ_SET_REGS, RTL8152_REQT_WRITE,
- value, index, tmp, size, 500);
+ RTL8152_REQ_SET_REGS, RTL8152_REQT_WRITE,
+ value, index, tmp, size, 500);
kfree(tmp);
@@ -652,7 +652,7 @@ int set_registers(struct r8152 *tp, u16 value, u16 index,
u16 size, void *data)
}
static int generic_ocp_read(struct r8152 *tp, u16 index, u16 size,
- void *data, u16 type)
+ void *data, u16 type)
{
u16 limit = 64;
int ret = 0;
@@ -692,7 +692,7 @@ static int generic_ocp_read(struct r8152 *tp, u16 index,
u16 size,
}
static int generic_ocp_write(struct r8152 *tp, u16 index, u16 byteen,
- u16 size, void *data, u16 type)
+u16 size, void *data, u16 type)
{
int ret;
u16 byteen_start, byteen_end, byen;
@@ -726,8 +726,8 @@ static int generic_ocp_write(struct r8152 *tp, u16 index,
u16 byteen,
while (size) {
if (size > limit) {
ret = set_registers(tp, index,
- type | BYTE_EN_DWORD,
- limit, data);
+ type | BYTE_EN_DWORD,
+ limit, data);
if (ret < 0)
goto error1;
@@ -736,8 +736,8 @@ static int generic_ocp_write(struct r8152 *tp, u16 index,
u16 byteen,
size -= limit;
} else {
ret = set_registers(tp, index,
- type | BYTE_EN_DWORD,
- size, data);
+ type | BYTE_EN_DWORD,
+ size, data);
if (ret < 0)
goto error1;
@@ -972,8 +972,8 @@ void write_mii_word(struct net_device *netdev, int phy_id,
int reg, int val)
usb_autopm_put_interface(tp->intf);
}
-static
-int r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags);
+static int
+r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags);
static inline void set_ethernet_addr(struct r8152 *tp)
{
@@ -1311,8 +1311,8 @@ static int alloc_all_mem(struct r8152 *tp)
tp->intr_interval = (int)ep_intr->desc.bInterval;
Re: [linux-usb] Is UAC1 (USB Audio Class 1.0) broken?
In order to get UAC1 working with my Ubuntu 12.04 LTS host, I have to make a
few changes to driver/usb/gadget/f_uac1.c
what changes ? care to send a patch ? Why do you need such change ? Are
you fixing a bug ?
Felipe,
Thanks. I have to apply below patch to fix the "-22" issue.
From: Xuebing Wang
Date: Wed, 20 Aug 2014 12:36:54 +0800
Subject: [PATCH 1/2] UAC1: enable USB gadget Audio Class revision 1.0
Fix below error message issue:
g_audio gadget: ep1out queue req: err = -22
This issue was observed on Freescale i.MX6SL EVK, kernel version 3.10.17
Signed-off-by: Xuebing Wang
---
arch/arm/configs/imx_v7_defconfig | 2 ++
drivers/usb/gadget/f_uac1.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/configs/imx_v7_defconfig
b/arch/arm/configs/imx_v7_defconfig
index b8d6ceb..30020d3 100644
--- a/arch/arm/configs/imx_v7_defconfig
+++ b/arch/arm/configs/imx_v7_defconfig
@@ -249,6 +249,8 @@ CONFIG_USB_PHY=y
CONFIG_NOP_USB_XCEIV=y
CONFIG_USB_MXS_PHY=y
CONFIG_USB_GADGET=y
+CONFIG_GADGET_UAC1=y
+CONFIG_USB_AUDIO=m
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_MASS_STORAGE=m
diff --git a/drivers/usb/gadget/f_uac1.c b/drivers/usb/gadget/f_uac1.c
index fa8ea4e..055961a 100644
--- a/drivers/usb/gadget/f_uac1.c
+++ b/drivers/usb/gadget/f_uac1.c
@@ -544,6 +544,7 @@ static int f_audio_set_alt(struct usb_function *f,
unsigned intf, unsigned alt)
{
struct f_audio*audio = func_to_audio(f);
struct usb_composite_dev *cdev = f->config->cdev;
+struct usb_gadget *gadget = cdev->gadget;
struct usb_ep *out_ep = audio->out_ep;
struct usb_request *req;
int i = 0, err = 0;
@@ -552,6 +553,7 @@ static int f_audio_set_alt(struct usb_function *f,
unsigned intf, unsigned alt)
if (intf == 1) {
if (alt == 1) {
+config_ep_by_speed(gadget, f, out_ep);
usb_ep_enable(out_ep);
out_ep->driver_data = audio;
audio->copy_buf = f_audio_buffer_alloc(audio_buf_size);
--
2.0.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
Re: [linux-usb] Is UAC1 (USB Audio Class 1.0) broken?
On Wed, Aug 20, 2014 at 05:29:57PM +0800, Xuebing Wang wrote:
>
> >>In order to get UAC1 working with my Ubuntu 12.04 LTS host, I have to make a
> >>few changes to driver/usb/gadget/f_uac1.c
> >what changes ? care to send a patch ? Why do you need such change ? Are
> >you fixing a bug ?
>
> Felipe,
>
> Thanks. I have to apply below patch to fix the "-22" issue.
>
>
>
>
> From: Xuebing Wang
> Date: Wed, 20 Aug 2014 12:36:54 +0800
> Subject: [PATCH 1/2] UAC1: enable USB gadget Audio Class revision 1.0
>
> Fix below error message issue:
> g_audio gadget: ep1out queue req: err = -22
>
> This issue was observed on Freescale i.MX6SL EVK, kernel version 3.10.17
>
> Signed-off-by: Xuebing Wang
> ---
> arch/arm/configs/imx_v7_defconfig | 2 ++
> drivers/usb/gadget/f_uac1.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/arm/configs/imx_v7_defconfig
> b/arch/arm/configs/imx_v7_defconfig
> index b8d6ceb..30020d3 100644
> --- a/arch/arm/configs/imx_v7_defconfig
> +++ b/arch/arm/configs/imx_v7_defconfig
> @@ -249,6 +249,8 @@ CONFIG_USB_PHY=y
> CONFIG_NOP_USB_XCEIV=y
> CONFIG_USB_MXS_PHY=y
> CONFIG_USB_GADGET=y
> +CONFIG_GADGET_UAC1=y
> +CONFIG_USB_AUDIO=m
> CONFIG_USB_ZERO=m
> CONFIG_USB_ETH=m
> CONFIG_USB_MASS_STORAGE=m
> diff --git a/drivers/usb/gadget/f_uac1.c b/drivers/usb/gadget/f_uac1.c
> index fa8ea4e..055961a 100644
> --- a/drivers/usb/gadget/f_uac1.c
> +++ b/drivers/usb/gadget/f_uac1.c
> @@ -544,6 +544,7 @@ static int f_audio_set_alt(struct usb_function
> *f, unsigned intf, unsigned alt)
> {
> struct f_audio*audio = func_to_audio(f);
> struct usb_composite_dev *cdev = f->config->cdev;
> +struct usb_gadget *gadget = cdev->gadget;
> struct usb_ep *out_ep = audio->out_ep;
> struct usb_request *req;
> int i = 0, err = 0;
> @@ -552,6 +553,7 @@ static int f_audio_set_alt(struct usb_function
> *f, unsigned intf, unsigned alt)
>
> if (intf == 1) {
> if (alt == 1) {
> +config_ep_by_speed(gadget, f, out_ep);
> usb_ep_enable(out_ep);
> out_ep->driver_data = audio;
> audio->copy_buf = f_audio_buffer_alloc(audio_buf_size);
> --
> 2.0.1
Hi Xuebing,
You may need to create patch based on the lastest kernel or usb-tree, besides,
it needs to split the patch, one for driver change, and another for platform
change.
The USB ML only accepts the usb driver change.
--
Best Regards,
Peter Chen
--
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/3] usb: add support for Diolan DLN-2 devices
From: Octavian Purdila
This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
Master Adapter DLN-2. Details about the device can be found here:
https://www.diolan.com/i2c/i2c_interface.html.
Information about the USB protocol can be found in the Programmer's
Reference Manual [1], see section 1.7.
Because the hardware has a single transmit endpoint and a single
receive endpoint the communication between the various DLN2 drivers
and the hardware will be muxed/demuxed by this driver.
The functional DLN2 drivers (i2c, GPIO, etc.) will have to register
themselves as DLN2 modules in order to send or receive data.
Each DLN2 module will be identified by the handle field within the DLN2
message header. If a DLN2 module issues multiple commands in parallel
they will be identified by the echo counter field in the message header.
The DLN2 modules can use the dln2_transfer() function to issue a
command and wait for its response. They can also use an asynchronous
mode of operation, in which case a receive callback function is going
to be notified when messages for a specific handle are received.
Because the hardware reserves handle 0 for GPIO events, the driver
also reserves handle 0. It will be allocated to a DLN2 module only if
it is explicitly requested.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Octavian Purdila
---
drivers/usb/misc/Kconfig | 6 +
drivers/usb/misc/Makefile | 1 +
drivers/usb/misc/dln2.c | 719 ++
include/linux/usb/dln2.h | 146 ++
4 files changed, 872 insertions(+)
create mode 100644 drivers/usb/misc/dln2.c
create mode 100644 include/linux/usb/dln2.h
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 76d7720..953f521 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -255,3 +255,9 @@ config USB_LINK_LAYER_TEST
This driver is for generating specific traffic for Super Speed Link
Layer Test Device. Say Y only when you want to conduct USB Super Speed
Link Layer Test for host controllers.
+
+config USB_DLN2
+ tristate "Diolan DLN2 USB Driver"
+ help
+ This adds USB support for Diolan USB-I2C/SPI/GPIO
+ Master Adapter DLN-2.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 65b0402..767264e 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_USB_USS720) += uss720.o
obj-$(CONFIG_USB_SEVSEG) += usbsevseg.o
obj-$(CONFIG_USB_YUREX)+= yurex.o
obj-$(CONFIG_USB_HSIC_USB3503) += usb3503.o
+obj-$(CONFIG_USB_DLN2) += dln2.o
obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
obj-$(CONFIG_USB_LINK_LAYER_TEST) += lvstest.o
diff --git a/drivers/usb/misc/dln2.c b/drivers/usb/misc/dln2.c
new file mode 100644
index 000..5bfa850
--- /dev/null
+++ b/drivers/usb/misc/dln2.c
@@ -0,0 +1,719 @@
+/*
+ * Driver for the Diolan DLN-2 USB adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ * i2c-diolan-u2c.c
+ * Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"usb-dln2"
+
+#define DLN2_GENERIC_MODULE_ID 0x00
+#define DLN2_GENERIC_CMD(cmd) DLN2_CMD(cmd, DLN2_GENERIC_MODULE_ID)
+
+/* generic commands */
+#define CMD_GET_DEVICE_VER DLN2_GENERIC_CMD(0x30)
+#define CMD_GET_DEVICE_SN DLN2_GENERIC_CMD(0x31)
+
+#define DLN2_HW_ID 0x200
+
+#define DLN2_USB_TIMEOUT 100 /* in ms */
+
+#define DLN2_MAX_RX_SLOTS 16
+
+#include
+
+struct dln2_rx_context {
+ struct completion done;
+ struct urb *urb;
+ bool connected;
+};
+
+struct dln2_rx_slots {
+ /* RX slots bitmap */
+ DECLARE_BITMAP(bmap, DLN2_MAX_RX_SLOTS);
+
+ /* used to wait for a free RX slot */
+ wait_queue_head_t wq;
+
+ /* used to wait for an RX operation to complete */
+ struct dln2_rx_context slots[DLN2_MAX_RX_SLOTS];
+
+ /* avoid races between free_rx_slot and dln2_transfer_rx_cb */
+ spinlock_t lock;
+};
+
+static int find_free_slot(struct dln2_rx_slots *rxs, int *slot)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&rxs->lock, flags);
+
+ *slot = bitmap_find_free_region(rxs->bmap, DLN2_MAX_RX_SLOTS, 0) - 1;
+
+ if (*slot >= 0) {
+ struct dln2_rx_context *rxc = &rxs->slots[*slot];
+
+ init_completion(&rxc->done);
+ rxc->connected = true;
+ }
+
+ spin_unlock_irqrestore(&rxs->lock, flags);
+
+ return *slot >= 0;
+}
+
+static int alloc_rx_slot
[PATCH 0/3] dln-2: Add support for Diolan DLN-2 devices
This patch series adds support for Diolan USB-I2C/GPIO Master Adapter DLN-2. Details about device can be found here: https://www.diolan.com/i2c/i2c_interface.html. There is no support for SPI part yet. Daniel Baluta (1): gpio: add support for the Diolan DLN-2 USB-GPIO driver Laurentiu Palcu (1): i2c: add support for Diolan DLN-2 USB-I2C adapter Octavian Purdila (1): usb: add support for Diolan DLN-2 devices drivers/gpio/Kconfig | 13 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-dln2.c | 571 + drivers/i2c/busses/Kconfig| 11 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-dln2.c | 328 +++ drivers/usb/misc/Kconfig | 6 + drivers/usb/misc/Makefile | 1 + drivers/usb/misc/dln2.c | 719 ++ include/linux/usb/dln2.h | 146 + 10 files changed, 1797 insertions(+) create mode 100644 drivers/gpio/gpio-dln2.c create mode 100644 drivers/i2c/busses/i2c-dln2.c create mode 100644 drivers/usb/misc/dln2.c create mode 100644 include/linux/usb/dln2.h -- 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 2/3] i2c: add support for Diolan DLN-2 USB-I2C adapter
From: Laurentiu Palcu
This patch adds support for the Diolan DLN-2 I2C master module. Due
to hardware limitations it does not support SMBUS quick commands.
Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 6.2.2 for the I2C
master module commands and responses.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Laurentiu Palcu
---
drivers/i2c/busses/Kconfig| 11 ++
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-dln2.c | 328 ++
3 files changed, 340 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-dln2.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2ac87fa..06b1e89 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1021,4 +1021,15 @@ config SCx200_ACB
This support is also available as a module. If so, the module
will be called scx200_acb.
+config I2C_DLN2
+ tristate "Diolan DLN-2 USB I2C adapter"
+ depends on USB
+ select USB_DLN2
+ help
+ If you say yes to this option, support will be included for Diolan
+ DLN2, a USB to I2C interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-dln2.
+
endmenu
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 49bf07e..3118fea 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -100,5 +100,6 @@ obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
obj-$(CONFIG_I2C_PCA_ISA) += i2c-pca-isa.o
obj-$(CONFIG_I2C_SIBYTE) += i2c-sibyte.o
obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
+obj-$(CONFIG_I2C_DLN2) += i2c-dln2.o
ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/busses/i2c-dln2.c b/drivers/i2c/busses/i2c-dln2.c
new file mode 100644
index 000..7befbb0
--- /dev/null
+++ b/drivers/i2c/busses/i2c-dln2.c
@@ -0,0 +1,328 @@
+/*
+ * Driver for the Diolan DLN-2 USB-I2C adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ * i2c-diolan-u2c.c
+ * Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"i2c-dln2"
+
+#define DLN2_I2C_MODULE_ID 0x03
+#define DLN2_I2C_CMD(cmd) DLN2_CMD(cmd, DLN2_I2C_MODULE_ID)
+
+/* I2C commands */
+#define CMD_I2C_GET_PORT_COUNT DLN2_I2C_CMD(0x00)
+#define CMD_I2C_ENABLE DLN2_I2C_CMD(0x01)
+#define CMD_I2C_DISABLEDLN2_I2C_CMD(0x02)
+#define CMD_I2C_IS_ENABLED DLN2_I2C_CMD(0x03)
+#define CMD_I2C_SET_FREQUENCY DLN2_I2C_CMD(0x04)
+#define CMD_I2C_GET_FREQUENCY DLN2_I2C_CMD(0x05)
+#define CMD_I2C_WRITE DLN2_I2C_CMD(0x06)
+#define CMD_I2C_READ DLN2_I2C_CMD(0x07)
+#define CMD_I2C_SCAN_DEVICES DLN2_I2C_CMD(0x08)
+#define CMD_I2C_PULLUP_ENABLE DLN2_I2C_CMD(0x09)
+#define CMD_I2C_PULLUP_DISABLE DLN2_I2C_CMD(0x0A)
+#define CMD_I2C_PULLUP_IS_ENABLED DLN2_I2C_CMD(0x0B)
+#define CMD_I2C_TRANSFER DLN2_I2C_CMD(0x0C)
+#define CMD_I2C_SET_MAX_REPLY_COUNTDLN2_I2C_CMD(0x0D)
+#define CMD_I2C_GET_MAX_REPLY_COUNTDLN2_I2C_CMD(0x0E)
+#define CMD_I2C_GET_MIN_FREQUENCY DLN2_I2C_CMD(0x40)
+#define CMD_I2C_GET_MAX_FREQUENCY DLN2_I2C_CMD(0x41)
+
+#define DLN2_I2C_FREQ_FAST 40
+#define DLN2_I2C_FREQ_STD 10
+
+#define DLN2_I2C_MAX_XFER_SIZE 256
+
+static struct dln2_mod *dln2_i2c_mod;
+
+/* Structure to hold all of our device specific stuff */
+struct dln2_i2c {
+ struct i2c_adapter adapter; /* i2c related things */
+ struct dln2_dev *dln2;
+};
+
+static uint frequency = DLN2_I2C_FREQ_STD; /* I2C clock frequency in Hz */
+
+module_param(frequency, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(frequency, "I2C clock frequency in hertz");
+
+static int dln2_i2c_set_state(struct dln2_i2c *dev, u8 state)
+{
+ int ret;
+ u8 port = 0;
+
+ ret = dln2_transfer(dev->dln2, dln2_i2c_mod,
+ state ? CMD_I2C_ENABLE : CMD_I2C_DISABLE,
+ &port, sizeof(port), NULL, NULL);
+
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+#define dln2_i2c_enable(dev) dln2_i2c_set_state(dev, 1)
+#define dln2_i2c_disable(dev) dln2_i2c_set_state(dev, 0)
+
+static int dln2_i2c_set_frequency(struct dln2_i2c *dev, u32 freq)
+{
+ int ret;
+ struct tx_data {
+ u8 port;
+ __le32 freq;
+ } __packed tx;
+
+ tx.port = 0;
+ tx.freq = cpu_to_le32(freq);
+
+ ret = dln2_transfer
[PATCH 3/3] gpio: add support for the Diolan DLN-2 USB-GPIO driver
This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module.
Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 2.9 for the GPIO
module commands and responses.
[1] https://www.diolan.com/downloads/dln-api-manual.pdf
Signed-off-by: Daniel Baluta
---
drivers/gpio/Kconfig | 13 ++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-dln2.c | 571 +++
3 files changed, 585 insertions(+)
create mode 100644 drivers/gpio/gpio-dln2.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 9de1515..1da9857 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -897,4 +897,17 @@ config GPIO_VIPERBOARD
River Tech's viperboard.h for detailed meaning
of the module parameters.
+config GPIO_DLN2
+ tristate "Diolan DLN2 GPIO support"
+ depends on USB
+ select USB_DLN2
+ select IRQ_DOMAIN
+
+ help
+ Select this option to enable GPIO driver for the Diolan DLN2
+ board.
+
+ This driver can also be built as a module. If so, the module
+ will be called gpio-dln2.
+
endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 5d024e3..eaa97a0 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_GPIO_CRYSTAL_COVE) += gpio-crystalcove.o
obj-$(CONFIG_GPIO_DA9052) += gpio-da9052.o
obj-$(CONFIG_GPIO_DA9055) += gpio-da9055.o
obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
+obj-$(CONFIG_GPIO_DLN2)+= gpio-dln2.o
obj-$(CONFIG_GPIO_DWAPB) += gpio-dwapb.o
obj-$(CONFIG_GPIO_EM) += gpio-em.o
obj-$(CONFIG_GPIO_EP93XX) += gpio-ep93xx.o
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
new file mode 100644
index 000..20d2e07
--- /dev/null
+++ b/drivers/gpio/gpio-dln2.c
@@ -0,0 +1,571 @@
+/*
+ * Driver for the Diolan DLN-2 USB-GPIO adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME "gpio-dln2"
+
+#define DLN2_GPIO_ID 0x01
+
+#define CMD_GPIO_GET_PORT_COUNTDLN2_CMD(0x00, DLN2_GPIO_ID)
+#define CMD_GPIO_GET_PIN_COUNT DLN2_CMD(0x01, DLN2_GPIO_ID)
+#define CMD_GPIO_SET_DEBOUNCE DLN2_CMD(0x04, DLN2_GPIO_ID)
+#define CMD_GPIO_GET_DEBOUNCE DLN2_CMD(0x05, DLN2_GPIO_ID)
+#define CMD_GPIO_PORT_GET_VAL DLN2_CMD(0x06, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_GET_VAL DLN2_CMD(0x0B, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_SET_OUT_VAL DLN2_CMD(0x0C, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_GET_OUT_VAL DLN2_CMD(0x0D, DLN2_GPIO_ID)
+#define CMD_GPIO_CONDITION_MET_EV DLN2_CMD(0x0F, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_ENABLEDLN2_CMD(0x10, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_DISABLE DLN2_CMD(0x11, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_SET_DIRECTION DLN2_CMD(0x13, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_GET_DIRECTION DLN2_CMD(0x14, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_SET_EVENT_CFG DLN2_CMD(0x1E, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_GET_EVENT_CFG DLN2_CMD(0x1F, DLN2_GPIO_ID)
+
+#define DLN2_GPIO_EVENT_NONE 0
+#define DLN2_GPIO_EVENT_CHANGE 1
+#define DLN2_GPIO_EVENT_LVL_HIGH 2
+#define DLN2_GPIO_EVENT_LVL_LOW3
+#define DLN2_GPIO_EVENT_CHANGE_RISING 0x11
+#define DLN2_GPIO_EVENT_CHANGE_FALLING 0x21
+#define DLN2_GPIO_EVENT_MASK 0x0F
+
+struct dln2_mod *dln2_gpio_mod, *dln2_irq_mod;
+
+#define DLN2_GPIO_MAX_PINS 32
+
+struct dln2_irq_work {
+ struct work_struct work;
+ struct dln2_gpio *dev;
+ int pin, type;
+};
+
+struct dln2_gpio {
+ struct dln2_dev *dln2;
+
+ struct gpio_chip gpio;
+
+ struct irq_domain *irq_domain;
+ DECLARE_BITMAP(irqs_masked, DLN2_GPIO_MAX_PINS);
+ DECLARE_BITMAP(irqs_enabled, DLN2_GPIO_MAX_PINS);
+ DECLARE_BITMAP(irqs_pending, DLN2_GPIO_MAX_PINS);
+ struct dln2_irq_work irq_work[DLN2_GPIO_MAX_PINS];
+};
+
+struct dln2_gpio_pin {
+ __le16 pin;
+} __packed;
+
+struct dln2_gpio_pin_val {
+ __le16 pin;
+ u8 value;
+} __packed;
+
+int dln2_gpio_get_pin_count(struct dln2_dev *dln2)
+{
+ __le16 count;
+ int ret, len = sizeof(count);
+
+ ret = dln2_transfer(dln2, dln2_gpio_mod, CMD_GPIO_GET_PIN_COUNT,
+ NULL, 0, &count, &len);
+ if (ret < 0)
+ return ret;
+
+ return le16_to_cpu(count);
+}
+
+static int dln2_gpio_pin_cmd(struct dln2_dev *dln2, int cmd, unsigned pin)
+{
+ struct dln2_gpio_pin req = {
+
Re: [PATCH v4 2/3] usb: gadget: f_fs: add ioctl returning ep descriptor
Hello.
On 8/20/2014 9:46 AM, Robert Baldyga wrote:
This patch introduces ioctl named FUNCTIONFS_ENDPOINT_DESC, which
returns endpoint descriptor to userspace. It works only if function
is active.
Signed-off-by: Robert Baldyga
[...]
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index 0154b28..900896e 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -265,6 +265,12 @@ struct usb_functionfs_event {
*/
#define FUNCTIONFS_ENDPOINT_REVMAP _IO('g', 129)
+/*
+ * Returns endpoint descriptor. In funciton is not active returns -ENODEV.
s/funciton/function/.
WBR, 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: [PATCH net-next 4/4] r8152: support firmware files
2014-08-20 10:58 GMT+02:00 Hayes Wang: > The firmware file is composed of the fw header and the commands. Each > command has the following type. > > cmd(2 bytes) + length(2 bytes) + data(variable bytes) > +static bool rtl_fw_format_ok(struct rtl_fw *rtl_fw) > + start = le32_to_cpu(fw_header->fw_start); > + if (start > fw->size) > + goto out; since "start" is an offset in an array of size "fw->size" this should check for ">=" and if a command is at least cmd(2 bytes) + length(2 bytes), shouldn't this check for "start >= fw->size - 4"? -- Daniele Forsi -- 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 net-next 4/4] r8152: support firmware files
Daniele Forsi [mailto:dfo...@gmail.com] > Sent: Wednesday, August 20, 2014 8:01 PM > To: Hayes Wang > Cc: net...@vger.kernel.org; nic_swsd; > linux-ker...@vger.kernel.org; USB list > Subject: Re: [PATCH net-next 4/4] r8152: support firmware files [...] > > + start = le32_to_cpu(fw_header->fw_start); > > + if (start > fw->size) > > + goto out; > > since "start" is an offset in an array of size "fw->size" this should > check for ">=" and if a command is at least cmd(2 bytes) + length(2 > bytes), shouldn't this check for "start >= fw->size - 4"? Is this necessary? Besides the check of the "start", there are checks of the "size" and rtl_fw_data_ok(). I think they cover the situations which you indicate. Best Regards, Hayes -- 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 net-next 3/4] r8152: remove clear_bp function
Hello.
On 8/20/2014 12:58 PM, Hayes Wang wrote:
The functions are used to update the firmware. Move the actions into
the firmware files.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 24
1 file changed, 24 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 33dcc97..937d132 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
[...]
@@ -2248,7 +2226,6 @@ static void r8152b_hw_phy_cfg(struct r8152 *tp)
r8152b_disable_aldps(tp);
- rtl_clear_bp(tp);
Why leave 2 empty lines? One is enough.
r8152b_enable_aldps(tp);
set_bit(PHY_RESET, &tp->flags);
@@ -2404,7 +2381,6 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
r8152_mdio_write(tp, MII_BMCR, data);
}
- r8153_clear_bp(tp);
Ditto.
if (tp->version == RTL_VER_03) {
data = ocp_reg_read(tp, OCP_EEE_CFG);
WBR, 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 reset xhci_hcd for ELAN touchscreen
On Mon, 14 Jul 2014, Johan Hovold wrote:
> From 8101c0dfd42a232f1d2872de4f412d8d61d5646f Mon Sep 17 00:00:00 2001
> From: Johan Hovold
> Date: Mon, 14 Jul 2014 18:43:31 +0200
> Subject: [PATCH] HID: usbhid: add HID_QUIRK_IN
>
> Add quirk to submit the interrupt-in urb already at start() rather than
> at open().
>
> This is needed for devices that disconnects from the bus unless the
> interrupt endpoint has been polled at least once or when not responding
> to input events.
It's not really super-nice, but if no other way around it has been found
to be possible in USB core, I am willing to take this.
> ---
> drivers/hid/usbhid/hid-core.c | 26 +++---
> include/linux/hid.h | 1 +
> 2 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index 7b88f4c..4b5d986 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -82,7 +82,7 @@ static int hid_start_in(struct hid_device *hid)
> struct usbhid_device *usbhid = hid->driver_data;
>
> spin_lock_irqsave(&usbhid->lock, flags);
> - if (hid->open > 0 &&
> + if ((hid->open > 0 || hid->quirks & HID_QUIRK_IN) &&
> !test_bit(HID_DISCONNECTED, &usbhid->iofl) &&
> !test_bit(HID_SUSPENDED, &usbhid->iofl) &&
> !test_and_set_bit(HID_IN_RUNNING, &usbhid->iofl)) {
> @@ -292,6 +292,8 @@ static void hid_irq_in(struct urb *urb)
> case 0: /* success */
> usbhid_mark_busy(usbhid);
> usbhid->retry_delay = 0;
> + if ((hid->quirks & HID_QUIRK_IN) && !hid->open)
> + break;
> hid_input_report(urb->context, HID_INPUT_REPORT,
>urb->transfer_buffer,
>urb->actual_length, 1);
> @@ -734,8 +736,10 @@ void usbhid_close(struct hid_device *hid)
> if (!--hid->open) {
> spin_unlock_irq(&usbhid->lock);
> hid_cancel_delayed_stuff(usbhid);
> - usb_kill_urb(usbhid->urbin);
> - usbhid->intf->needs_remote_wakeup = 0;
> + if (!(hid->quirks & HID_QUIRK_IN)) {
> + usb_kill_urb(usbhid->urbin);
> + usbhid->intf->needs_remote_wakeup = 0;
> + }
> } else {
> spin_unlock_irq(&usbhid->lock);
> }
> @@ -1133,6 +1137,20 @@ static int usbhid_start(struct hid_device *hid)
>
> set_bit(HID_STARTED, &usbhid->iofl);
>
> + hid->quirks |= HID_QUIRK_IN;/* FIXME */
This of course needs to be set on per-device basis :)
> + if (hid->quirks & HID_QUIRK_IN) {
> + ret = usb_autopm_get_interface(usbhid->intf);
> + if (ret)
> + goto fail;
> + usbhid->intf->needs_remote_wakeup = 1;
> + ret = hid_start_in(hid);
> + if (ret) {
> + dev_err(&hid->dev,
> + "failed to start in urb: %d\n", ret);
> + }
> + usb_autopm_put_interface(usbhid->intf);
> + }
> +
> /* Some keyboards don't work until their LEDs have been set.
>* Since BIOSes do set the LEDs, it must be safe for any device
>* that supports the keyboard boot protocol.
> @@ -1165,6 +1183,8 @@ static void usbhid_stop(struct hid_device *hid)
> if (WARN_ON(!usbhid))
> return;
>
> + usbhid->intf->needs_remote_wakeup = 0;
> +
> clear_bit(HID_STARTED, &usbhid->iofl);
> spin_lock_irq(&usbhid->lock); /* Sync with error and led handlers */
> set_bit(HID_DISCONNECTED, &usbhid->iofl);
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 77632cf..13f81ae 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -286,6 +286,7 @@ struct hid_item {
> #define HID_QUIRK_HIDINPUT_FORCE 0x0080
> #define HID_QUIRK_NO_EMPTY_INPUT 0x0100
> #define HID_QUIRK_NO_INIT_INPUT_REPORTS 0x0200
> +#define HID_QUIRK_IN 0x0400
0x0400 has been removed before dynamic quirks started to be possible,
so there is no potential clash, that's fine.
I'd just propose some more descriptive name for the quirk ... how about
something like HID_QUIRK_EARLY_INTERRUPT?
Thanks,
--
Jiri Kosina
SUSE Labs
--
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 4/7] xhci: Remove "FIXME - check all the stream rings for pending cancellations"
From: Hans de Goede Even though a Set TR deq ptr command operates on a ring, and an endpoint can have multiple rings, we can have only one Set TR deq ptr command pending. When an endpoint with streams halts or is stopped to unlink urbs, there will only be at most one ring active / one td being executed (the td stopped_td points to). So when we reset the endpoint (for a halt), or the stop command completes, we will queue one Set TR deq ptr command at most, cancelled urbs on other stream rings then the one being executed will have there trbs turned to nops, and once the hcd gets around to execute that stream ring they will be simply skipped. So the SET_DEQ_PENDING flag in the endpoint is sufficient protection against starting the endpoing before all stream rings are cleaned up. Signed-off-by: Hans de Goede Acked-by: Mathias Nyman Signed-off-by: Mathias Nyman --- drivers/usb/host/xhci-ring.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index f58856b..5a85605 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -327,7 +327,6 @@ void xhci_ring_ep_doorbell(struct xhci_hcd *xhci, * We don't want to restart any stream rings if there's a set dequeue * pointer command pending because the device can choose to start any * stream once the endpoint is on the HW schedule. -* FIXME - check all the stream rings for pending cancellations. */ if ((ep_state & EP_HALT_PENDING) || (ep_state & SET_DEQ_PENDING) || (ep_state & EP_HALTED)) -- 1.8.3.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
[PATCH 7/7] usb: xhci_suspend is not stopping the root hub timer for the shared HCD
From: Al Cooper V2 - Restart polling (which will restart the timer) for the shared HCD in xhci_resume(). xhci_suspend() will stop the primary HCD's root hub timer, but leaves the shared HCD's timer running. This change adds stopping of the shared HCD timer. Signed-off-by: Al Cooper Signed-off-by: Mathias Nyman --- drivers/usb/host/xhci.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 4b82d62..6f7b303 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -871,6 +871,8 @@ int xhci_suspend(struct xhci_hcd *xhci) xhci_dbg(xhci, "%s: stopping port polling.\n", __func__); clear_bit(HCD_FLAG_POLL_RH, &hcd->flags); del_timer_sync(&hcd->rh_timer); + clear_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags); + del_timer_sync(&xhci->shared_hcd->rh_timer); spin_lock_irq(&xhci->lock); clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags); @@ -1075,6 +1077,8 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated) xhci_dbg(xhci, "%s: starting port polling.\n", __func__); set_bit(HCD_FLAG_POLL_RH, &hcd->flags); usb_hcd_poll_rh_status(hcd); + set_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags); + usb_hcd_poll_rh_status(xhci->shared_hcd); return retval; } -- 1.8.3.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 net-next 4/4] r8152: support firmware files
2014-08-20 14:35 GMT+02:00 Hayes Wang: > Is this necessary? Besides the check of the "start", > there are checks of the "size" and rtl_fw_data_ok(). > I think they cover the situations which you indicate. it's not necessary and it's better checked later as you did! -- Daniele Forsi -- 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 5/7] xhci: Always ring the doorbell for active eps when a Set TR deq ptr cmd completes
From: Hans de Goede Even if the stream for which the command was intended has been freed in the mean time. This ensures that things start rolling again after an unlink / halt. Signed-off-by: Hans de Goede Acked-by: Mathias Nyman Signed-off-by: Mathias Nyman --- drivers/usb/host/xhci-ring.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 5a85605..b9fe9c5 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -987,8 +987,7 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd *xhci, int slot_id, xhci_warn(xhci, "WARN Set TR deq ptr command for freed stream ID %u\n", stream_id); /* XXX: Harmless??? */ - dev->eps[ep_index].ep_state &= ~SET_DEQ_PENDING; - return; + goto cleanup; } ep_ctx = xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index); @@ -1053,6 +1052,7 @@ static void xhci_handle_cmd_set_deq(struct xhci_hcd *xhci, int slot_id, } } +cleanup: dev->eps[ep_index].ep_state &= ~SET_DEQ_PENDING; dev->eps[ep_index].queued_deq_seg = NULL; dev->eps[ep_index].queued_deq_ptr = NULL; -- 1.8.3.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
[PATCH 1/7] xhci: Log extra info on "ERROR Transfer event TRB DMA ptr not part of current TD"
From: Hans de Goede
Lately (with the use of uas / bulk-streams) we have been seeing several
cases where this error triggers (which should never happen).
Add some extra logging to make debugging these errors easier.
Signed-off-by: Hans de Goede
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-mem.c | 4 +++-
drivers/usb/host/xhci-ring.c | 26 +-
drivers/usb/host/xhci.h | 6 +++---
3 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8056d90..26129d3 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1903,7 +1903,7 @@ static int xhci_test_trb_in_td(struct xhci_hcd *xhci,
start_dma = xhci_trb_virt_to_dma(input_seg, start_trb);
end_dma = xhci_trb_virt_to_dma(input_seg, end_trb);
- seg = trb_in_td(input_seg, start_trb, end_trb, input_dma);
+ seg = trb_in_td(xhci, input_seg, start_trb, end_trb, input_dma, false);
if (seg != result_seg) {
xhci_warn(xhci, "WARN: %s TRB math test %d failed!\n",
test_name, test_number);
@@ -1917,6 +1917,8 @@ static int xhci_test_trb_in_td(struct xhci_hcd *xhci,
end_trb, end_dma);
xhci_warn(xhci, "Expected seg %p, got seg %p\n",
result_seg, seg);
+ trb_in_td(xhci, input_seg, start_trb, end_trb, input_dma,
+ true);
return -1;
}
return 0;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 60fb52a..fd0e784 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1722,10 +1722,12 @@ cleanup:
* TRB in this TD, this function returns that TRB's segment. Otherwise it
* returns 0.
*/
-struct xhci_segment *trb_in_td(struct xhci_segment *start_seg,
+struct xhci_segment *trb_in_td(struct xhci_hcd *xhci,
+ struct xhci_segment *start_seg,
union xhci_trb *start_trb,
union xhci_trb *end_trb,
- dma_addr_t suspect_dma)
+ dma_addr_t suspect_dma,
+ booldebug)
{
dma_addr_t start_dma;
dma_addr_t end_seg_dma;
@@ -1744,6 +1746,15 @@ struct xhci_segment *trb_in_td(struct xhci_segment
*start_seg,
/* If the end TRB isn't in this segment, this is set to 0 */
end_trb_dma = xhci_trb_virt_to_dma(cur_seg, end_trb);
+ if (debug)
+ xhci_warn(xhci,
+ "Looking for event-dma %016llx trb-start
%016llx trb-end %016llx seg-start %016llx seg-end %016llx\n",
+ (unsigned long long)suspect_dma,
+ (unsigned long long)start_dma,
+ (unsigned long long)end_trb_dma,
+ (unsigned long long)cur_seg->dma,
+ (unsigned long long)end_seg_dma);
+
if (end_trb_dma > 0) {
/* The end TRB is in this segment, so suspect should be
here */
if (start_dma <= end_trb_dma) {
@@ -2476,8 +2487,8 @@ static int handle_tx_event(struct xhci_hcd *xhci,
td_num--;
/* Is this a TRB in the currently executing TD? */
- event_seg = trb_in_td(ep_ring->deq_seg, ep_ring->dequeue,
- td->last_trb, event_dma);
+ event_seg = trb_in_td(xhci, ep_ring->deq_seg, ep_ring->dequeue,
+ td->last_trb, event_dma, false);
/*
* Skip the Force Stopped Event. The event_trb(event_dma) of FSE
@@ -2508,7 +2519,12 @@ static int handle_tx_event(struct xhci_hcd *xhci,
/* HC is busted, give up! */
xhci_err(xhci,
"ERROR Transfer event TRB DMA ptr not "
- "part of current TD\n");
+ "part of current TD ep_index %d "
+ "comp_code %u\n", ep_index,
+ trb_comp_code);
+ trb_in_td(xhci, ep_ring->deq_seg,
+ ep_ring->dequeue, td->last_trb,
+ event_dma, true);
return -ESHUTDOWN;
}
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index dace515..d544c75 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1804,9 +1804,9 @@ void xhci_reset_bandwidth(struct usb_hcd *hcd, struct
usb_device *udev);
/* xHCI ring, segment, TRB, and TD functions */
dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg, union xhci_trb *trb);
[PATCH 2/7] xhci: Move allocating of command for new_dequeue_state to queue_set_tr_deq()
From: Hans de Goede
There are multiple reasons for this:
1) This fixes a missing check for xhci_alloc_command failing in
xhci_handle_cmd_stop_ep()
2) This adds a warning when we cannot set the new dequeue state because of
xhci_alloc_command failing
3) It puts the allocation of the command after the sanity checks in
queue_set_tr_deq(), avoiding leaking the command if those fail
4) Since queue_set_tr_deq now owns the command it can free it if queue_command
fails
5) It reduces code duplication
Signed-off-by: Hans de Goede
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 35 ++-
drivers/usb/host/xhci.c | 7 +--
drivers/usb/host/xhci.h | 1 -
3 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index fd0e784..60f128b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -595,14 +595,12 @@ static void td_to_noop(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
}
}
-static int queue_set_tr_deq(struct xhci_hcd *xhci,
- struct xhci_command *cmd, int slot_id,
+static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
unsigned int ep_index, unsigned int stream_id,
struct xhci_segment *deq_seg,
union xhci_trb *deq_ptr, u32 cycle_state);
void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
- struct xhci_command *cmd,
unsigned int slot_id, unsigned int ep_index,
unsigned int stream_id,
struct xhci_dequeue_state *deq_state)
@@ -617,7 +615,7 @@ void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
deq_state->new_deq_ptr,
(unsigned long
long)xhci_trb_virt_to_dma(deq_state->new_deq_seg, deq_state->new_deq_ptr),
deq_state->new_cycle_state);
- queue_set_tr_deq(xhci, cmd, slot_id, ep_index, stream_id,
+ queue_set_tr_deq(xhci, slot_id, ep_index, stream_id,
deq_state->new_deq_seg,
deq_state->new_deq_ptr,
(u32) deq_state->new_cycle_state);
@@ -766,12 +764,8 @@ remove_finished_td:
/* If necessary, queue a Set Transfer Ring Dequeue Pointer command */
if (deq_state.new_deq_ptr && deq_state.new_deq_seg) {
- struct xhci_command *command;
- command = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
- xhci_queue_new_dequeue_state(xhci, command,
- slot_id, ep_index,
- ep->stopped_td->urb->stream_id,
- &deq_state);
+ xhci_queue_new_dequeue_state(xhci, slot_id, ep_index,
+ ep->stopped_td->urb->stream_id, &deq_state);
xhci_ring_cmd_db(xhci);
} else {
/* Otherwise ring the doorbell(s) to restart queued transfers */
@@ -3967,8 +3961,7 @@ int xhci_queue_stop_endpoint(struct xhci_hcd *xhci,
struct xhci_command *cmd,
/* Set Transfer Ring Dequeue Pointer command.
* This should not be used for endpoints that have streams enabled.
*/
-static int queue_set_tr_deq(struct xhci_hcd *xhci, struct xhci_command *cmd,
- int slot_id,
+static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
unsigned int ep_index, unsigned int stream_id,
struct xhci_segment *deq_seg,
union xhci_trb *deq_ptr, u32 cycle_state)
@@ -3980,6 +3973,8 @@ static int queue_set_tr_deq(struct xhci_hcd *xhci, struct
xhci_command *cmd,
u32 trb_sct = 0;
u32 type = TRB_TYPE(TRB_SET_DEQ);
struct xhci_virt_ep *ep;
+ struct xhci_command *cmd;
+ int ret;
addr = xhci_trb_virt_to_dma(deq_seg, deq_ptr);
if (addr == 0) {
@@ -3994,14 +3989,28 @@ static int queue_set_tr_deq(struct xhci_hcd *xhci,
struct xhci_command *cmd,
xhci_warn(xhci, "A Set TR Deq Ptr command is pending.\n");
return 0;
}
+
+ /* This function gets called from contexts where it cannot sleep */
+ cmd = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
+ if (!cmd) {
+ xhci_warn(xhci, "WARN Cannot submit Set TR Deq Ptr: ENOMEM\n");
+ return 0;
+ }
+
ep->queued_deq_seg = deq_seg;
ep->queued_deq_ptr = deq_ptr;
if (stream_id)
trb_sct = SCT_FOR_TRB(SCT_PRI_TR);
- return queue_command(xhci, cmd,
+ ret = queue_command(xhci, cmd,
lower_32_bits(addr) | trb_sct | cycle_state,
upper_32_bits(addr), trb_stream_id,
trb_slot_id | trb_ep_index | type, false);
+ if (ret < 0) {
+ xhci_free_command(xhci, cmd);
+ return ret;
+
[PATCH 0/7] xhci: patches for usb-next
Hi Greg These xhci patches are for usb-next and apply on top of 3.17-rc1 It contains Hans De Goede's xhci cleanups, and one small xhci suspend improvement. I'll be out hiking and unable to respond (no network whatsoeever) until mid next week, 27.8. -Mathias Al Cooper (1): usb: xhci_suspend is not stopping the root hub timer for the shared HCD Hans de Goede (6): xhci: Log extra info on "ERROR Transfer event TRB DMA ptr not part of current TD" xhci: Move allocating of command for new_dequeue_state to queue_set_tr_deq() xhci: Fold queue_set_tr_deq into xhci_queue_new_dequeue_state xhci: Remove "FIXME - check all the stream rings for pending cancellations" xhci: Always ring the doorbell for active eps when a Set TR deq ptr cmd completes xhci: xhci_ring_device: Ring stream ring bells for endpoints with streams drivers/usb/host/xhci-hub.c | 15 +++-- drivers/usb/host/xhci-mem.c | 4 +- drivers/usb/host/xhci-ring.c | 137 ++- drivers/usb/host/xhci.c | 11 ++-- drivers/usb/host/xhci.h | 7 +-- 5 files changed, 93 insertions(+), 81 deletions(-) -- 1.8.3.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
[PATCH 3/7] xhci: Fold queue_set_tr_deq into xhci_queue_new_dequeue_state
From: Hans de Goede
xhci_queue_new_dequeue_state is the only caller of queue_set_tr_deq
and queue_set_tr_deq checks for SET_DEQ_PENDING, where as
xhci_queue_new_dequeue_state sets it which is inconsistent.
Simply fold the 2 into one is a nice cleanup and fixes the inconsistency.
Signed-off-by: Hans de Goede
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 83 +---
1 file changed, 32 insertions(+), 51 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 60f128b..f58856b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -595,38 +595,6 @@ static void td_to_noop(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
}
}
-static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
- unsigned int ep_index, unsigned int stream_id,
- struct xhci_segment *deq_seg,
- union xhci_trb *deq_ptr, u32 cycle_state);
-
-void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
- unsigned int slot_id, unsigned int ep_index,
- unsigned int stream_id,
- struct xhci_dequeue_state *deq_state)
-{
- struct xhci_virt_ep *ep = &xhci->devs[slot_id]->eps[ep_index];
-
- xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
- "Set TR Deq Ptr cmd, new deq seg = %p (0x%llx dma), "
- "new deq ptr = %p (0x%llx dma), new cycle = %u",
- deq_state->new_deq_seg,
- (unsigned long long)deq_state->new_deq_seg->dma,
- deq_state->new_deq_ptr,
- (unsigned long
long)xhci_trb_virt_to_dma(deq_state->new_deq_seg, deq_state->new_deq_ptr),
- deq_state->new_cycle_state);
- queue_set_tr_deq(xhci, slot_id, ep_index, stream_id,
- deq_state->new_deq_seg,
- deq_state->new_deq_ptr,
- (u32) deq_state->new_cycle_state);
- /* Stop the TD queueing code from ringing the doorbell until
-* this command completes. The HC won't set the dequeue pointer
-* if the ring is running, and ringing the doorbell starts the
-* ring running.
-*/
- ep->ep_state |= SET_DEQ_PENDING;
-}
-
static void xhci_stop_watchdog_timer_in_irq(struct xhci_hcd *xhci,
struct xhci_virt_ep *ep)
{
@@ -3958,13 +3926,11 @@ int xhci_queue_stop_endpoint(struct xhci_hcd *xhci,
struct xhci_command *cmd,
trb_slot_id | trb_ep_index | type | trb_suspend, false);
}
-/* Set Transfer Ring Dequeue Pointer command.
- * This should not be used for endpoints that have streams enabled.
- */
-static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
- unsigned int ep_index, unsigned int stream_id,
- struct xhci_segment *deq_seg,
- union xhci_trb *deq_ptr, u32 cycle_state)
+/* Set Transfer Ring Dequeue Pointer command */
+void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
+ unsigned int slot_id, unsigned int ep_index,
+ unsigned int stream_id,
+ struct xhci_dequeue_state *deq_state)
{
dma_addr_t addr;
u32 trb_slot_id = SLOT_ID_FOR_TRB(slot_id);
@@ -3976,41 +3942,56 @@ static int queue_set_tr_deq(struct xhci_hcd *xhci, int
slot_id,
struct xhci_command *cmd;
int ret;
- addr = xhci_trb_virt_to_dma(deq_seg, deq_ptr);
+ xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
+ "Set TR Deq Ptr cmd, new deq seg = %p (0x%llx dma), new deq ptr
= %p (0x%llx dma), new cycle = %u",
+ deq_state->new_deq_seg,
+ (unsigned long long)deq_state->new_deq_seg->dma,
+ deq_state->new_deq_ptr,
+ (unsigned long long)xhci_trb_virt_to_dma(
+ deq_state->new_deq_seg, deq_state->new_deq_ptr),
+ deq_state->new_cycle_state);
+
+ addr = xhci_trb_virt_to_dma(deq_state->new_deq_seg,
+ deq_state->new_deq_ptr);
if (addr == 0) {
xhci_warn(xhci, "WARN Cannot submit Set TR Deq Ptr\n");
xhci_warn(xhci, "WARN deq seg = %p, deq pt = %p\n",
- deq_seg, deq_ptr);
- return 0;
+ deq_state->new_deq_seg, deq_state->new_deq_ptr);
+ return;
}
ep = &xhci->devs[slot_id]->eps[ep_index];
if ((ep->ep_state & SET_DEQ_PENDING)) {
xhci_warn(xhci, "WARN Cannot submit Set TR Deq Ptr\n");
xhci_warn(xhci, "A Set TR Deq Ptr command is pending.\n");
- return 0;
+ return;
}
/* This function gets called from contexts where it cannot sleep */
cmd = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
if (!cmd) {
[PATCH 6/7] xhci: xhci_ring_device: Ring stream ring bells for endpoints with streams
From: Hans de Goede
Signed-off-by: Hans de Goede
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index aa79e87..bb54783 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -319,12 +319,19 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
*/
void xhci_ring_device(struct xhci_hcd *xhci, int slot_id)
{
- int i;
+ int i, s;
+ struct xhci_virt_ep *ep;
+
+ for (i = 0; i < LAST_EP_INDEX + 1; i++) {
+ ep = &xhci->devs[slot_id]->eps[i];
- for (i = 0; i < LAST_EP_INDEX + 1; i++)
- if (xhci->devs[slot_id]->eps[i].ring &&
- xhci->devs[slot_id]->eps[i].ring->dequeue)
+ if (ep->ep_state & EP_HAS_STREAMS) {
+ for (s = 1; s < ep->stream_info->num_streams; s++)
+ xhci_ring_ep_doorbell(xhci, slot_id, i, s);
+ } else if (ep->ring && ep->ring->dequeue) {
xhci_ring_ep_doorbell(xhci, slot_id, i, 0);
+ }
+ }
return;
}
--
1.8.3.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 v5] phy: Renesas R-Car Gen2 PHY driver
Hi,
On Wednesday 23 July 2014 12:57 AM, Sergei Shtylyov wrote:
.
.
.
.
> Index: linux-phy/drivers/phy/phy-rcar-gen2.c
> ===
> --- /dev/null
> +++ linux-phy/drivers/phy/phy-rcar-gen2.c
> @@ -0,0 +1,341 @@
> +/*
> + * Renesas R-Car Gen2 PHY driver
> + *
> + * Copyright (C) 2014 Renesas Solutions Corp.
> + * Copyright (C) 2014 Cogent Embedded, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define USBHS_LPSTS 0x02
> +#define USBHS_UGCTRL 0x80
> +#define USBHS_UGCTRL20x84
> +#define USBHS_UGSTS 0x88/* The manuals have 0x90 */
> +
> +/* Low Power Status register (LPSTS) */
> +#define USBHS_LPSTS_SUSPM0x4000
> +
> +/* USB General control register (UGCTRL) */
> +#define USBHS_UGCTRL_CONNECT 0x0004
> +#define USBHS_UGCTRL_PLLRESET0x0001
> +
> +/* USB General control register 2 (UGCTRL2) */
> +#define USBHS_UGCTRL2_USB2SEL0x8000
> +#define USBHS_UGCTRL2_USB2SEL_PCI0x
> +#define USBHS_UGCTRL2_USB2SEL_USB30 0x8000
> +#define USBHS_UGCTRL2_USB0SEL0x0030
> +#define USBHS_UGCTRL2_USB0SEL_PCI0x0010
> +#define USBHS_UGCTRL2_USB0SEL_HS_USB 0x0030
> +
> +/* USB General status register (UGSTS) */
> +#define USBHS_UGSTS_LOCK 0x0300 /* The manuals have 0x3 */
> +
> +#define PHYS_PER_CHANNEL 2
> +
> +struct rcar_gen2_phy {
> + struct phy *phy;
> + struct rcar_gen2_channel *channel;
> + int number;
> + u32 select_value;
> +};
> +
> +struct rcar_gen2_channel {
> + struct device_node *of_node;
> + struct rcar_gen2_phy_driver *drv;
> + struct rcar_gen2_phy phys[PHYS_PER_CHANNEL];
> + int selected_phy;
> + u32 select_mask;
> +};
> +
> +struct rcar_gen2_phy_driver {
> + void __iomem *base;
> + struct clk *clk;
> + spinlock_t lock;
> + int num_channels;
> + struct rcar_gen2_channel *channels;
> +};
> +
> +static int rcar_gen2_phy_init(struct phy *p)
> +{
> + struct rcar_gen2_phy *phy = phy_get_drvdata(p);
> + struct rcar_gen2_channel *channel = phy->channel;
> + struct rcar_gen2_phy_driver *drv = channel->drv;
> + unsigned long flags;
> + u32 ugctrl2;
> +
> + /*
> + * Try to acquire exclusive access to PHY. The first driver calling
> + * phy_init() on a given channel wins, and all attempts to use another
> + * PHY on this channel will fail until phy_exit() is called by the first
> + * driver. Achieving this with cmpxcgh() should be SMP-safe.
> + */
> + if (cmpxchg(&channel->selected_phy, -1, phy->number) != -1)
> + return -EBUSY;
This should be done in phy_get no?
Can we add this in phy-core? There might be other users who want to have
exclusive access within the same phy provider.
Rest of it looks fine to me.
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] USB: pch_udc: USB gadget device support for Intel Quark X1000
Hi Greg, On Mon, Aug 04, 2014 at 10:22:54AM -0700, Chen, Alvin wrote: > From: Bryan O'Donoghue > > This patch is to enable the USB gadget device for Intel Quark X1000 > > Signed-off-by: Bryan O'Donoghue > Signed-off-by: Bing Niu > Signed-off-by: Alvin (Weike) Chen this patch is basically just a new device ID being added to an existing driver, do you mind if I add it to the -rc or you prefer to wait for v3.18 merge window ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5] ARM: dts: remove old USB2 PHY node hook for Arndale
On Thursday 14 August 2014 07:55 PM, Bartlomiej Zolnierkiewicz wrote:
> drivers/usb/phy/phy-samsung-usb2 driver got replaced by
> drivers/phy/phy-samsung-usb2 one. Remove the leftover hook
> from Arndale dts file.
>
> Cc: Mark Brown
> Cc: Kamil Debski
> Cc: Vivek Gautam
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Acked-by: Kyungmin Park
Acked-by: Kishon Vijay Abraham I
> ---
> arch/arm/boot/dts/exynos5250-arndale.dts | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index d0de1f5..dad8f9b 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -570,8 +570,4 @@
> connect-gpios = <&gpd1 7 1>;
> };
> };
> -
> - usb@1211 {
> - usb-phy = <&usb2_phy>;
> - };
> };
>
--
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 4/5] usb: phy: samsung: remove old USB 3.0 PHY driver
On Thursday 14 August 2014 07:55 PM, Bartlomiej Zolnierkiewicz wrote:
> drivers/usb/phy/phy-samsung-usb3 driver got replaced by
> drivers/phy/phy-samsung-usb3 one and is no longer used.
>
> Cc: Kamil Debski
> Cc: Vivek Gautam
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Acked-by: Kyungmin Park
Acked-by: Kishon Vijay Abraham I
> ---
> drivers/usb/phy/Kconfig| 8 -
> drivers/usb/phy/Makefile | 1 -
> drivers/usb/phy/phy-samsung-usb3.c | 350
> -
> 3 files changed, 359 deletions(-)
> delete mode 100644 drivers/usb/phy/phy-samsung-usb3.c
>
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index 452e252..0cd1f44 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -78,14 +78,6 @@ config SAMSUNG_USBPHY
> This driver provides common interface to interact, for Samsung USB
> 2.0 PHY
> driver and later for Samsung USB 3.0 PHY driver.
>
> -config SAMSUNG_USB3PHY
> - tristate "Samsung USB 3.0 PHY controller Driver"
> - select SAMSUNG_USBPHY
> - select USB_PHY
> - help
> - Enable this to support Samsung USB 3.0 (Super Speed) phy controller
> - for samsung SoCs.
> -
> config TWL6030_USB
> tristate "TWL6030 USB Transceiver Driver"
> depends on TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index c651005..75f2bba 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -15,7 +15,6 @@ obj-$(CONFIG_AM335X_CONTROL_USB)+= phy-am335x-control.o
> obj-$(CONFIG_AM335X_PHY_USB) += phy-am335x.o
> obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
> obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o
> -obj-$(CONFIG_SAMSUNG_USB3PHY)+= phy-samsung-usb3.o
> obj-$(CONFIG_TWL6030_USB)+= phy-twl6030-usb.o
> obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
> obj-$(CONFIG_USB_GPIO_VBUS) += phy-gpio-vbus-usb.o
> diff --git a/drivers/usb/phy/phy-samsung-usb3.c
> b/drivers/usb/phy/phy-samsung-usb3.c
> deleted file mode 100644
> index cc08192..000
> --- a/drivers/usb/phy/phy-samsung-usb3.c
> +++ /dev/null
> @@ -1,350 +0,0 @@
> -/* linux/drivers/usb/phy/phy-samsung-usb3.c
> - *
> - * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> - * http://www.samsung.com
> - *
> - * Author: Vivek Gautam
> - *
> - * Samsung USB 3.0 PHY transceiver; talks to DWC3 controller.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include "phy-samsung-usb.h"
> -
> -/*
> - * Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from clock
> core.
> - */
> -static u32 samsung_usb3phy_set_refclk(struct samsung_usbphy *sphy)
> -{
> - u32 reg;
> - u32 refclk;
> -
> - refclk = sphy->ref_clk_freq;
> -
> - reg = PHYCLKRST_REFCLKSEL_EXT_REFCLK |
> - PHYCLKRST_FSEL(refclk);
> -
> - switch (refclk) {
> - case FSEL_CLKSEL_50M:
> - reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
> - PHYCLKRST_SSC_REFCLKSEL(0x00));
> - break;
> - case FSEL_CLKSEL_20M:
> - reg |= (PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF |
> - PHYCLKRST_SSC_REFCLKSEL(0x00));
> - break;
> - case FSEL_CLKSEL_19200K:
> - reg |= (PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF |
> - PHYCLKRST_SSC_REFCLKSEL(0x88));
> - break;
> - case FSEL_CLKSEL_24M:
> - default:
> - reg |= (PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF |
> - PHYCLKRST_SSC_REFCLKSEL(0x88));
> - break;
> - }
> -
> - return reg;
> -}
> -
> -static void samsung_exynos5_usb3phy_enable(struct samsung_usbphy *sphy)
> -{
> - void __iomem *regs = sphy->regs;
> - u32 phyparam0;
> - u32 phyparam1;
> - u32 linksystem;
> - u32 phybatchg;
> - u32 phytest;
> - u32 phyclkrst;
> -
> - /* Reset USB 3.0 PHY */
> - writel(0x0, regs + EXYNOS5_DRD_PHYREG0);
> -
> - phyparam0 = readl(regs + EXYNOS5_DRD_PHYPARAM0);
> - /* Select PHY CLK source */
> - phyparam0 &= ~PHYPARAM0_REF_USE_PAD;
> - /* Set Loss-of-Signal Detector sensitivity */
> - phyparam0 &= ~PHYPARAM0_REF_LOSLEVEL_MASK;
> - phyparam0 |= PHYPARAM0_REF_LOSLEVEL;
> - writel(phyparam0, regs + EXYNOS5_DRD_PHYPARAM0);
> -
> - writel(0x0,
Re: [PATCH 2/5] ARM: dts: remove old USB2 PHY node for Exynos5250
On Thursday 14 August 2014 07:55 PM, Bartlomiej Zolnierkiewicz wrote:
> drivers/usb/phy/phy-samsung-usb2 driver got replaced by
> drivers/phy/phy-samsung-usb2 one. Remove the leftover
> USB2 PHY node (EHCI/OHCI USB nodes are using the new one
> already) from Exynos5250 dtsi file.
>
> Cc: Mark Brown
> Cc: Kamil Debski
> Cc: Vivek Gautam
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Acked-by: Kyungmin Park
Acked-by: Kishon Vijay Abraham I
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 15 ---
> 1 file changed, 15 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 492e1ef..f21b9aa 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -603,21 +603,6 @@
> };
> };
>
> - usb2_phy: usbphy@1213 {
> - compatible = "samsung,exynos5250-usb2phy";
> - reg = <0x1213 0x100>;
> - clocks = <&clock CLK_FIN_PLL>, <&clock CLK_USB2>;
> - clock-names = "ext_xtal", "usbhost";
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges;
> -
> - usbphy-sys {
> - reg = <0x10040704 0x8>,
> - <0x10050230 0x4>;
> - };
> - };
> -
> usb2_phy_gen: phy@1213 {
> compatible = "samsung,exynos5250-usb2-phy";
> reg = <0x1213 0x100>;
>
--
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 3/5] usb: phy: samsung: remove old USB 2.0 PHY driver
On Thursday 14 August 2014 07:55 PM, Bartlomiej Zolnierkiewicz wrote:
> drivers/usb/phy/phy-samsung-usb2 driver got replaced by
> drivers/phy/phy-samsung-usb2 one and is no longer used.
>
> Cc: Kamil Debski
> Cc: Vivek Gautam
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Acked-by: Kyungmin Park
Acked-by: Kishon Vijay Abraham I
One suggestion though would be to use git format-patch -D while deleting the
file :-)
Thanks
Kishon
> ---
> drivers/usb/phy/Kconfig| 8 -
> drivers/usb/phy/Makefile | 1 -
> drivers/usb/phy/phy-samsung-usb2.c | 541
> -
> 3 files changed, 550 deletions(-)
> delete mode 100644 drivers/usb/phy/phy-samsung-usb2.c
>
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index e253fa0..452e252 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -78,14 +78,6 @@ config SAMSUNG_USBPHY
> This driver provides common interface to interact, for Samsung USB
> 2.0 PHY
> driver and later for Samsung USB 3.0 PHY driver.
>
> -config SAMSUNG_USB2PHY
> - tristate "Samsung USB 2.0 PHY controller Driver"
> - select SAMSUNG_USBPHY
> - select USB_PHY
> - help
> - Enable this to support Samsung USB 2.0 (High Speed) PHY controller
> - driver for Samsung SoCs.
> -
> config SAMSUNG_USB3PHY
> tristate "Samsung USB 3.0 PHY controller Driver"
> select SAMSUNG_USBPHY
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index 24a9133..c651005 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -15,7 +15,6 @@ obj-$(CONFIG_AM335X_CONTROL_USB)+= phy-am335x-control.o
> obj-$(CONFIG_AM335X_PHY_USB) += phy-am335x.o
> obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
> obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o
> -obj-$(CONFIG_SAMSUNG_USB2PHY)+= phy-samsung-usb2.o
> obj-$(CONFIG_SAMSUNG_USB3PHY)+= phy-samsung-usb3.o
> obj-$(CONFIG_TWL6030_USB)+= phy-twl6030-usb.o
> obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
> diff --git a/drivers/usb/phy/phy-samsung-usb2.c
> b/drivers/usb/phy/phy-samsung-usb2.c
> deleted file mode 100644
> index b3ba866..000
> --- a/drivers/usb/phy/phy-samsung-usb2.c
> +++ /dev/null
> @@ -1,541 +0,0 @@
> -/* linux/drivers/usb/phy/phy-samsung-usb2.c
> - *
> - * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> - * http://www.samsung.com
> - *
> - * Author: Praveen Paneri
> - *
> - * Samsung USB2.0 PHY transceiver; talks to S3C HS OTG controller, EHCI-S5P
> and
> - * OHCI-EXYNOS controllers.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include "phy-samsung-usb.h"
> -
> -static int samsung_usbphy_set_host(struct usb_otg *otg, struct usb_bus *host)
> -{
> - if (!otg)
> - return -ENODEV;
> -
> - if (!otg->host)
> - otg->host = host;
> -
> - return 0;
> -}
> -
> -static bool exynos5_phyhost_is_on(void __iomem *regs)
> -{
> - u32 reg;
> -
> - reg = readl(regs + EXYNOS5_PHY_HOST_CTRL0);
> -
> - return !(reg & HOST_CTRL0_SIDDQ);
> -}
> -
> -static void samsung_exynos5_usb2phy_enable(struct samsung_usbphy *sphy)
> -{
> - void __iomem *regs = sphy->regs;
> - u32 phyclk = sphy->ref_clk_freq;
> - u32 phyhost;
> - u32 phyotg;
> - u32 phyhsic;
> - u32 ehcictrl;
> - u32 ohcictrl;
> -
> - /*
> - * phy_usage helps in keeping usage count for phy
> - * so that the first consumer enabling the phy is also
> - * the last consumer to disable it.
> - */
> -
> - atomic_inc(&sphy->phy_usage);
> -
> - if (exynos5_phyhost_is_on(regs)) {
> - dev_info(sphy->dev, "Already power on PHY\n");
> - return;
> - }
> -
> - /* Host configuration */
> - phyhost = readl(regs + EXYNOS5_PHY_HOST_CTRL0);
> -
> - /* phy reference clock configuration */
> - phyhost &= ~HOST_CTRL0_FSEL_MASK;
> - phyhost |= HOST_CTRL0_FSEL(phyclk);
> -
> - /* host phy reset */
> - phyhost &= ~(HOST_CTRL0_PHYSWRST |
> - HOST_CTRL0_PHYSWRSTALL |
> - HOST_CTRL0_SIDDQ |
> - /* Enable normal mode of operation */
> - HOST_CTRL0_FORCESUSPEND |
> - HOST_CTRL0_FORCESLEEP);
> -
> - /* Link reset */
> - phyhost
Re: [PATCH 5/5] usb: phy: samsung: remove old common USB PHY code
On Thursday 14 August 2014 07:55 PM, Bartlomiej Zolnierkiewicz wrote:
> drivers/usb/phy/phy-samsung-usb[2,3] drivers got replaced by
> drivers/phy/phy-samsung-usb[2,3] ones and the old common Samsung
> USB PHY code is no longer used.
>
> Cc: Kamil Debski
> Cc: Vivek Gautam
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Acked-by: Kyungmin Park
Acked-by: Kishon Vijay Abraham I
> ---
> drivers/usb/phy/Kconfig | 7 -
> drivers/usb/phy/Makefile | 1 -
> drivers/usb/phy/phy-samsung-usb.c| 241 --
> drivers/usb/phy/phy-samsung-usb.h| 349
> ---
> include/linux/platform_data/samsung-usbphy.h | 27 ---
> 5 files changed, 625 deletions(-)
> delete mode 100644 drivers/usb/phy/phy-samsung-usb.c
> delete mode 100644 drivers/usb/phy/phy-samsung-usb.h
> delete mode 100644 include/linux/platform_data/samsung-usbphy.h
>
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index 0cd1f44..7012a82 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -71,13 +71,6 @@ config AM335X_PHY_USB
> This driver provides PHY support for that phy which part for the
> AM335x SoC.
>
> -config SAMSUNG_USBPHY
> - tristate
> - help
> - Enable this to support Samsung USB phy helper driver for Samsung SoCs.
> - This driver provides common interface to interact, for Samsung USB
> 2.0 PHY
> - driver and later for Samsung USB 3.0 PHY driver.
> -
> config TWL6030_USB
> tristate "TWL6030 USB Transceiver Driver"
> depends on TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index 75f2bba..1e38a6f 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -14,7 +14,6 @@ obj-$(CONFIG_TAHVO_USB) += phy-tahvo.o
> obj-$(CONFIG_AM335X_CONTROL_USB) += phy-am335x-control.o
> obj-$(CONFIG_AM335X_PHY_USB) += phy-am335x.o
> obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
> -obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o
> obj-$(CONFIG_TWL6030_USB)+= phy-twl6030-usb.o
> obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
> obj-$(CONFIG_USB_GPIO_VBUS) += phy-gpio-vbus-usb.o
> diff --git a/drivers/usb/phy/phy-samsung-usb.c
> b/drivers/usb/phy/phy-samsung-usb.c
> deleted file mode 100644
> index ac025ca..000
> --- a/drivers/usb/phy/phy-samsung-usb.c
> +++ /dev/null
> @@ -1,241 +0,0 @@
> -/* linux/drivers/usb/phy/phy-samsung-usb.c
> - *
> - * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> - * http://www.samsung.com
> - *
> - * Author: Praveen Paneri
> - *
> - * Samsung USB-PHY helper driver with common function calls;
> - * interacts with Samsung USB 2.0 PHY controller driver and later
> - * with Samsung USB 3.0 PHY driver.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include "phy-samsung-usb.h"
> -
> -int samsung_usbphy_parse_dt(struct samsung_usbphy *sphy)
> -{
> - struct device_node *usbphy_sys;
> -
> - /* Getting node for system controller interface for usb-phy */
> - usbphy_sys = of_get_child_by_name(sphy->dev->of_node, "usbphy-sys");
> - if (!usbphy_sys) {
> - dev_err(sphy->dev, "No sys-controller interface for usb-phy\n");
> - return -ENODEV;
> - }
> -
> - sphy->pmuregs = of_iomap(usbphy_sys, 0);
> -
> - if (sphy->pmuregs == NULL) {
> - dev_err(sphy->dev, "Can't get usb-phy pmu control register\n");
> - goto err0;
> - }
> -
> - sphy->sysreg = of_iomap(usbphy_sys, 1);
> -
> - /*
> - * Not returning error code here, since this situation is not fatal.
> - * Few SoCs may not have this switch available
> - */
> - if (sphy->sysreg == NULL)
> - dev_warn(sphy->dev, "Can't get usb-phy sysreg cfg register\n");
> -
> - of_node_put(usbphy_sys);
> -
> - return 0;
> -
> -err0:
> - of_node_put(usbphy_sys);
> - return -ENXIO;
> -}
> -EXPORT_SYMBOL_GPL(samsung_usbphy_parse_dt);
> -
> -/*
> - * Set isolation here for phy.
> - * Here 'on = true' would mean USB PHY block is isolated, hence
> - * de-activated and vice-versa.
> - */
> -void samsung_usbphy_set_isolation_4210(struct samsung_usbphy *sphy, bool on)
> -{
> - void __iomem *reg = NULL;
> - u32 reg_val;
> - u32 en_mask = 0;
Re: [PATCH 0/7] g_webcam: Preparation for configfs
Hi, On Mon, Aug 18, 2014 at 09:45:08PM +0200, Laurent Pinchart wrote: > Hi Andrzej, > > Thank you for the patches. The series looks good, I only had a few comments. > > I have rebased the patches on top of my UVC gadget branch, addressed my > comments (the modified patches are marked as such in the commit message) and > pushed the result to > > git://linuxtv.org/pinchartl/media.git uvc/gadget > > Would you be able to test the result and hopefully ack it ? If everything is > fine with you there's no need to submit a new version. > > On Wednesday 16 July 2014 16:54:10 Andrzej Pietrasiewicz wrote: > > This patch series prepares the webcam gadget for supporting configfs. > > Compared to the RFC: > > > > http://www.spinics.net/lists/linux-usb/msg103301.html > > > > - the patch fixing potential memory leak has been removed, > > because it is already in Laurent's tree. > > > > - a patch changing function names to avoid conflicts has been added, > > because now the said functions are not static. > > > > - Laurent's comments have been addressed. > > > > This series _does not_ contain a patch adding configfs support, > > as Laurent suggests - first have the preparation series merged. > > > > This series depends on the gadget directory cleanup series: > > > > www.spinics.net/lists/linux-usb/msg110545.html > > > > Andrzej Pietrasiewicz (7): > > usb: gadget: uvc: move module parameters from f_uvc > > usb: gadget: uvc: rename functions to avoid conflicts with host uvc > > usb: gadget: uvc: separately compile some components of f_uvc > > usb: gadget: f_uvc: convert f_uvc to new function interface > > usb: gadget: webcam: convert webcam to new interface of f_uvc > > usb: gadget: f_uvc: remove compatibility layer > > usb: gadget: f_uvc: use usb_gstrings_attach all patches acked-by laurent are in my testing/next already. -- balbi signature.asc Description: Digital signature
Re: [RFC] usb: gadget: serial: remove PREFIX macro
Hi, On Fri, Jul 18, 2014 at 11:39:46AM +0200, Richard Leitner wrote: > Remove the ttyGS PREFIX macro from u_serial.c and replace all occurences with > the hardcoded ttyGS string. > > This macro was mostly used in a few debug/warning messages and a lot of > hardcoded ttyGS existed beneath. It may have been used for renaming the > tty, but if done so most debug messages would have ignored this because > of the hardcoded strings. > > Due to the fact the usage of this PREFIX instead of the hardcoded strings > in all debug calls would have resulted in a hard to read/grep code it > is removed completely. > > Signed-off-by: Richard Leitner patch looks fine, can you resend with RFC in the subject ? -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: serial: replace {V,}DBG macro with dev_{v,}dbg
Hi, On Fri, Jul 18, 2014 at 11:11:21AM +0200, Richard Leitner wrote: > Replace the VDBG and DBG macro with the kernels "proper" debug macros > (dev_vdbg and dev_dbg) in f_acm.c, f_obex.c & f_serial.c > > Signed-off-by: Richard Leitner please rebase this one on top of v3.17-rc1 -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: phy: msm: Make phy_reset clk and reset line optional.
On Thu, Jul 17, 2014 at 09:16:40PM +0100, Srinivas Kandagatla wrote: > This patch makes the phy reset clk and reset line optional as this clk > is not available on boards like IFC6410 with APQ8064. > > phy-reset clk is only used as argument to the mach level callbacks, so > this patch adds condition before clk_get calls so that the driver > wouldn't fail on SOCs which do not have this support. > > Signed-off-by: Srinivas Kandagatla > --- > Hi Felipe, > > With this new patch now the error message is only printed if the SOC actually > supports > the phy reset clk, for SOCs like APQ8064 where there is no phy reset clock or > the callback which takes it there is no point in doing a clk_get call in the > first place. doesn't apply. Please rebase on top of v3.17-rc1 -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 4/6] usb: common: add API to get if the platform supports TPL
Hi,
On Tue, Aug 19, 2014 at 09:51:55AM +0800, Peter Chen wrote:
> The TPL (Targeted Peripheral List) is used for targeted hosts
> (non-PC hosts), and it can be used at USB OTG & EH certification
> and some specific products which need white list.
>
> Signed-off-by: Peter Chen
> ---
> drivers/usb/common/usb-common.c | 15 +++
> include/linux/usb/of.h |5 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/usb/common/usb-common.c b/drivers/usb/common/usb-common.c
> index 6dfd30a..b530fd4 100644
> --- a/drivers/usb/common/usb-common.c
> +++ b/drivers/usb/common/usb-common.c
> @@ -139,6 +139,21 @@ enum usb_device_speed of_usb_get_maximum_speed(struct
> device_node *np)
> }
> EXPORT_SYMBOL_GPL(of_usb_get_maximum_speed);
>
> +/**
> + * of_usb_host_tpl_support - to get if Targeted Peripheral List is supported
> + * for given targeted hosts (non-PC hosts)
> + * @np: Pointer to the given device_node
> + *
> + * The function gets if the targeted hosts support TPL or not
> + */
> +bool of_usb_host_tpl_support(struct device_node *np)
> +{
> + if (of_find_property(np, "tpl-support", NULL))
> + return true;
> +
> + return false;
please don't. Quite frankly, TPL support in Linux is quite braindead.
The way it's done it prevents USB from being used as an accessory port.
I talked to the USB-IF long ago and I was told that the spec is a bit
badly worded but preventing new drivers from being installed is wrong.
What we really need is a notification for when Linux can't bind any
driver to the new device. That would be an unsupported device.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] USB: pch_udc: USB gadget device support for Intel Quark X1000
On Wed, Aug 20, 2014 at 09:54:46AM -0500, Felipe Balbi wrote: > Hi Greg, > > On Mon, Aug 04, 2014 at 10:22:54AM -0700, Chen, Alvin wrote: > > From: Bryan O'Donoghue > > > > This patch is to enable the USB gadget device for Intel Quark X1000 > > > > Signed-off-by: Bryan O'Donoghue > > Signed-off-by: Bing Niu > > Signed-off-by: Alvin (Weike) Chen > > this patch is basically just a new device ID being added to an existing > driver, do you mind if I add it to the -rc or you prefer to wait for > v3.18 merge window ? New ids are fine for -rc and stable kernels, don't wait for 3.18. 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] USB: pch_udc: USB gadget device support for Intel Quark X1000
On Wed, Aug 20, 2014 at 11:15:05AM -0500, Greg KH wrote: > On Wed, Aug 20, 2014 at 09:54:46AM -0500, Felipe Balbi wrote: > > Hi Greg, > > > > On Mon, Aug 04, 2014 at 10:22:54AM -0700, Chen, Alvin wrote: > > > From: Bryan O'Donoghue > > > > > > This patch is to enable the USB gadget device for Intel Quark X1000 > > > > > > Signed-off-by: Bryan O'Donoghue > > > Signed-off-by: Bing Niu > > > Signed-off-by: Alvin (Weike) Chen > > > > this patch is basically just a new device ID being added to an existing > > driver, do you mind if I add it to the -rc or you prefer to wait for > > v3.18 merge window ? > > New ids are fine for -rc and stable kernels, don't wait for 3.18. it does a little more than that as it needs to select the proper PCI BAR for Quark, I guess that's still fine ? Original patch here: http://marc.info/?l=linux-kernel&m=140714448511662&w=2 -- balbi signature.asc Description: Digital signature
Re: [RFC] usb: gadget: serial: remove PREFIX macro
Hello. On 08/20/2014 07:54 PM, Felipe Balbi wrote: Remove the ttyGS PREFIX macro from u_serial.c and replace all occurences with the hardcoded ttyGS string. This macro was mostly used in a few debug/warning messages and a lot of hardcoded ttyGS existed beneath. It may have been used for renaming the tty, but if done so most debug messages would have ignored this because of the hardcoded strings. Due to the fact the usage of this PREFIX instead of the hardcoded strings in all debug calls would have resulted in a hard to read/grep code it is removed completely. Signed-off-by: Richard Leitner patch looks fine, can you resend with RFC in the subject ? s/with/without/? WBR, 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: [PATCH 0/7] g_webcam: Preparation for configfs
Hi Felipe, On Wednesday 20 August 2014 10:39:43 Felipe Balbi wrote: > On Mon, Aug 18, 2014 at 09:45:08PM +0200, Laurent Pinchart wrote: > > Hi Andrzej, > > > > Thank you for the patches. The series looks good, I only had a few > > comments. > > > > I have rebased the patches on top of my UVC gadget branch, addressed my > > comments (the modified patches are marked as such in the commit message) > > and pushed the result to > > > > git://linuxtv.org/pinchartl/media.git uvc/gadget > > > > Would you be able to test the result and hopefully ack it ? If everything > > is fine with you there's no need to submit a new version. > > > > On Wednesday 16 July 2014 16:54:10 Andrzej Pietrasiewicz wrote: > > > This patch series prepares the webcam gadget for supporting configfs. > > > Compared to the RFC: > > > > > > http://www.spinics.net/lists/linux-usb/msg103301.html > > > > > > - the patch fixing potential memory leak has been removed, > > > because it is already in Laurent's tree. > > > > > > - a patch changing function names to avoid conflicts has been added, > > > because now the said functions are not static. > > > > > > - Laurent's comments have been addressed. > > > > > > This series _does not_ contain a patch adding configfs support, > > > as Laurent suggests - first have the preparation series merged. > > > > > > This series depends on the gadget directory cleanup series: > > > > > > www.spinics.net/lists/linux-usb/msg110545.html > > > > > > Andrzej Pietrasiewicz (7): > > > usb: gadget: uvc: move module parameters from f_uvc > > > usb: gadget: uvc: rename functions to avoid conflicts with host uvc > > > usb: gadget: uvc: separately compile some components of f_uvc > > > usb: gadget: f_uvc: convert f_uvc to new function interface > > > usb: gadget: webcam: convert webcam to new interface of f_uvc > > > usb: gadget: f_uvc: remove compatibility layer > > > usb: gadget: f_uvc: use usb_gstrings_attach > > all patches acked-by laurent are in my testing/next already. I've modified a couple of those. If Andrzej is fine with the modifications I'll prepare a branch and send you a pull request. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2/2] usb: gadget: f_uvc: Move to video_ioctl2
Hi Michael, On Wednesday 20 August 2014 09:55:10 Michael Grzeschik wrote: > On Mon, Aug 18, 2014 at 11:16:36PM +0200, Laurent Pinchart wrote: > > On Monday 18 August 2014 18:24:26 Hans Verkuil wrote: > > > On 08/18/2014 05:06 PM, Laurent Pinchart wrote: > > > > Simplify ioctl handling by using video_ioctl2. > > > > > > Are you able to test this on actual hardware? And if so, can you run > > > v4l2-compliance? > > > > I'm afraid not. I don't have a platform with an up and running USB > > peripheral controller at the moment. > > You could test it with dummy_hcd gadget on an virtual or non usb machine. Thank you for pointing this out. -- 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: [PATCH] USB: pch_udc: USB gadget device support for Intel Quark X1000
On Wed, Aug 20, 2014 at 11:20:09AM -0500, Felipe Balbi wrote: > On Wed, Aug 20, 2014 at 11:15:05AM -0500, Greg KH wrote: > > On Wed, Aug 20, 2014 at 09:54:46AM -0500, Felipe Balbi wrote: > > > Hi Greg, > > > > > > On Mon, Aug 04, 2014 at 10:22:54AM -0700, Chen, Alvin wrote: > > > > From: Bryan O'Donoghue > > > > > > > > This patch is to enable the USB gadget device for Intel Quark X1000 > > > > > > > > Signed-off-by: Bryan O'Donoghue > > > > Signed-off-by: Bing Niu > > > > Signed-off-by: Alvin (Weike) Chen > > > > > > this patch is basically just a new device ID being added to an existing > > > driver, do you mind if I add it to the -rc or you prefer to wait for > > > v3.18 merge window ? > > > > New ids are fine for -rc and stable kernels, don't wait for 3.18. > > it does a little more than that as it needs to select the proper PCI > BAR for Quark, I guess that's still fine ? Yes, as it's totally safe if you don't have this hardware, so all should be good. 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 v2 2/3] usb: gadget/uvc: also handle v4l2 ioctl ENUM_FMT
Hi Hans and Michael,
On Wednesday 20 August 2014 02:06:54 Hans Verkuil wrote:
> On 08/19/2014 05:01 PM, Laurent Pinchart wrote:
> > Hi Michael,
> >
> > Thank you for the patch.
> >
> > (CC'ing Hans Verkuil and the linux-media mailing list)
> >
> > On Friday 08 August 2014 17:38:58 Michael Grzeschik wrote:
> >> This patch adds ENUM_FMT as possible ioctl to the uvc v4l2 device.
> >> That makes userspace applications with a generic IOCTL calling
> >> convention make also use of it.
> >>
> >> Signed-off-by: Michael Grzeschik
> >> ---
> >>
> >> v1 -> v2:
> >> - changed first switch case to simple if
> >> - added separate function
> >> - added description field
> >> - bail out on array boundaries
> >>
> >> drivers/usb/gadget/uvc_v4l2.c | 30 --
> >> 1 file changed, 28 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/usb/gadget/uvc_v4l2.c
> >> b/drivers/usb/gadget/uvc_v4l2.c
> >> index ad48e81..58633bf 100644
> >> --- a/drivers/usb/gadget/uvc_v4l2.c
> >> +++ b/drivers/usb/gadget/uvc_v4l2.c
> >> @@ -55,14 +55,30 @@ struct uvc_format
> >> {
> >>u8 bpp;
> >>u32 fcc;
> >> + char *description;
> >> };
> >>
> >> static struct uvc_format uvc_formats[] = {
> >> - { 16, V4L2_PIX_FMT_YUYV },
> >> - { 0, V4L2_PIX_FMT_MJPEG },
> >> + { 16, V4L2_PIX_FMT_YUYV, "YUV 4:2:2" },
> >> + { 0, V4L2_PIX_FMT_MJPEG, "MJPEG" },
> >
> > Format descriptions are currently duplicated in every driver, causing
> > higher memory usage and different descriptions for the same format
> > depending on the driver. Hans, should we try to fix this ?
>
> Yes, we should. It's been on my todo list for ages, but at a very low
> priority. I'm not planning to work on this in the near future, but if
> someone else wants to work on this, then just go ahead.
Michael, would you like to give this a try, or should I do it ?
--
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: [PATCH 0/7] g_webcam: Preparation for configfs
On Wed, Aug 20, 2014 at 07:02:29PM +0200, Laurent Pinchart wrote: > Hi Felipe, > > On Wednesday 20 August 2014 10:39:43 Felipe Balbi wrote: > > On Mon, Aug 18, 2014 at 09:45:08PM +0200, Laurent Pinchart wrote: > > > Hi Andrzej, > > > > > > Thank you for the patches. The series looks good, I only had a few > > > comments. > > > > > > I have rebased the patches on top of my UVC gadget branch, addressed my > > > comments (the modified patches are marked as such in the commit message) > > > and pushed the result to > > > > > > git://linuxtv.org/pinchartl/media.git uvc/gadget > > > > > > Would you be able to test the result and hopefully ack it ? If everything > > > is fine with you there's no need to submit a new version. > > > > > > On Wednesday 16 July 2014 16:54:10 Andrzej Pietrasiewicz wrote: > > > > This patch series prepares the webcam gadget for supporting configfs. > > > > Compared to the RFC: > > > > > > > > http://www.spinics.net/lists/linux-usb/msg103301.html > > > > > > > > - the patch fixing potential memory leak has been removed, > > > > because it is already in Laurent's tree. > > > > > > > > - a patch changing function names to avoid conflicts has been added, > > > > because now the said functions are not static. > > > > > > > > - Laurent's comments have been addressed. > > > > > > > > This series _does not_ contain a patch adding configfs support, > > > > as Laurent suggests - first have the preparation series merged. > > > > > > > > This series depends on the gadget directory cleanup series: > > > > > > > > www.spinics.net/lists/linux-usb/msg110545.html > > > > > > > > Andrzej Pietrasiewicz (7): > > > > usb: gadget: uvc: move module parameters from f_uvc > > > > usb: gadget: uvc: rename functions to avoid conflicts with host uvc > > > > usb: gadget: uvc: separately compile some components of f_uvc > > > > usb: gadget: f_uvc: convert f_uvc to new function interface > > > > usb: gadget: webcam: convert webcam to new interface of f_uvc > > > > usb: gadget: f_uvc: remove compatibility layer > > > > usb: gadget: f_uvc: use usb_gstrings_attach > > > > all patches acked-by laurent are in my testing/next already. > > I've modified a couple of those. If Andrzej is fine with the modifications > I'll prepare a branch and send you a pull request. alright, I'll drop them -- balbi signature.asc Description: Digital signature
[GIT PULL] USB fixes for v3.17-rc2
Hi Greg, Here's my first set of fixes for this merge window. All patches have soaked in mailing list for a while, and what I could, I tested on the platforms I have. Please consider merging on top of your usb-linus branch. cheers The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v3.17-rc2 for you to fetch changes up to 5d19703822da2a8e9161302aa918c8e45a4c5eee: usb: gadget: remove $(PWD) in ccflags-y (2014-08-20 11:16:02 -0500) usb: fixes for v3.17-rc2 Here's our first set of fixes for v3.17-rc cycle. Most fixes are pretty minor changes like the signedness bug in dwc3, or the wrong string format on MUSB. The most interesting part is the addition of Intel Quark X1000 support to PCH UDC. Signed-of-by: Felipe Balbi Alexey Khoroshilov (1): usb: dbgp gadget: fix use after free in dbgp_unbind() Arjun Sreedharan (1): usb: phy: return -ENODEV on failure of try_module_get Bo Shen (1): usb: atmel_usba_udc: fix it to deal with final dma channel Bryan O'Donoghue (1): usb: pch_udc: usb gadget device support for Intel Quark X1000 Dan Carpenter (1): usb: dwc3: omap: signedness bug in dwc3_omap_set_utmi_mode() Hans Wennborg (1): usb: musb: ux500: fix decimal printf format specifiers prefixed with 0x Himangi Saraogi (1): usb: phy: drop kfree of devm_kzalloc's data Jingoo Han (1): usb: phy: samsung: Fix wrong bit mask for PHYPARAM1_PCS_TXDEEMPH Julia Lawall (1): usb: gadget: fix error return code Li RongQing (1): Revert "usb: gadget: u_ether: synchronize with transmit when stopping queue" Michael Grzeschik (1): usb: gadget: uvc: fix possible lockup in uvc gadget Philippe Reynes (1): usb: gadget: remove $(PWD) in ccflags-y Wei Yongjun (3): usb: gadget: Fix return value check in ep_write() usb: gadget: Fix return value check in r8a66597_probe() usb: phy: msm: Fix return value check in msm_otg_probe() drivers/usb/dwc3/dwc3-omap.c| 2 +- drivers/usb/gadget/Makefile | 2 +- drivers/usb/gadget/function/Makefile| 4 ++-- drivers/usb/gadget/function/u_ether.c | 3 --- drivers/usb/gadget/function/uvc_video.c | 3 +++ drivers/usb/gadget/legacy/Makefile | 6 +++--- drivers/usb/gadget/legacy/dbgp.c| 2 ++ drivers/usb/gadget/legacy/inode.c | 2 +- drivers/usb/gadget/udc/Kconfig | 3 ++- drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +- drivers/usb/gadget/udc/fusb300_udc.c| 8 ++-- drivers/usb/gadget/udc/pch_udc.c| 22 +++--- drivers/usb/gadget/udc/r8a66597-udc.c | 4 ++-- drivers/usb/musb/ux500_dma.c| 2 +- drivers/usb/phy/phy-gpio-vbus-usb.c | 4 +--- drivers/usb/phy/phy-msm-usb.c | 4 ++-- drivers/usb/phy/phy-samsung-usb.h | 2 +- drivers/usb/phy/phy.c | 3 +++ 18 files changed, 51 insertions(+), 27 deletions(-) -- 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
[GIT PULL] USB-serial fixes for v3.17-rc2
Hi Greg, Here are some fixes and new device IDs for v3.17-rc2 for you to pull. All have been in linux-next. Thanks, Johan The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-3.17-rc2 for you to fetch changes up to 646907f5bfb0782c731ae9ff6fb63471a3566132: USB: ftdi_sio: Added PID for new ekey device (2014-08-18 13:09:27 +0200) USB-serial fixes for v3.17-rc2 These updates fix the log level for some option log messages that started bothering people after a recent change. They also fix some issues reported against the zte_ev driver by moving most device ids back from the zte_ev driver to the option driver (and removing two duplicate ids). The zte_ev driver is planned to be removed in 3.18. Some new device ids are also added. Brennan Ashton (1): USB: option: add VIA Telecom CDS7 chipset device id Greg KH (1): USB: serial: pl2303: add device id for ztek device Jaša Bartelj (1): USB: ftdi_sio: Added PID for new ekey device Johan Hovold (5): USB: option: reduce interrupt-urb logging verbosity Revert "USB: option,zte_ev: move most ZTE CDMA devices to zte_ev" USB: zte_ev: remove duplicate Gobi PID USB: zte_ev: remove duplicate Qualcom PID USB: ftdi_sio: add Basic Micro ATOM Nano USB2Serial PID drivers/usb/serial/ftdi_sio.c | 3 +++ drivers/usb/serial/ftdi_sio_ids.h | 7 +++ drivers/usb/serial/option.c | 31 --- drivers/usb/serial/pl2303.c | 1 + drivers/usb/serial/pl2303.h | 1 + drivers/usb/serial/zte_ev.c | 20 6 files changed, 40 insertions(+), 23 deletions(-) -- 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] usb: gadget/uvc: remove DRIVER_VERSION{,_NUMBER}
On Thu, Aug 14, 2014 at 02:10:38PM +0200, Laurent Pinchart wrote: > Hi Michael, > > Thank you for the patch. > > On Thursday 14 August 2014 13:09:44 Michael Grzeschik wrote: > > As the driver is mainline we can remove the version numbers. > > > > Signed-off-by: Michael Grzeschik > > Acked-by: Laurent Pinchart doesn't apply, please rebase on top of v3.17-rc1 and resend wiht Laurent's Ack. Thanks -- balbi signature.asc Description: Digital signature
RE: [PATCH] usb: dwc2: gadget: Set the default EP max packet value as 8 bytes
> From: Jingoo Han [mailto:jg1@samsung.com]
> Sent: Tuesday, August 19, 2014 8:04 PM
>
> Set the default EP max packet value as 8 bytes, because in the case
> of low-speed, 'ep_mps' is not set. Thus, the default value of 'ep_mps'
> should be considered for the case of low-speed.
>
> Signed-off-by: Jingoo Han
> ---
> - Based on the latest 'usb-linus' branch.
>
> drivers/usb/dwc2/gadget.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 2a6f76b0075e..7c9618e916e2 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -1901,7 +1901,7 @@ static void s3c_hsotg_epint(struct s3c_hsotg *hsotg,
> unsigned int idx,
> static void s3c_hsotg_irq_enumdone(struct s3c_hsotg *hsotg)
> {
> u32 dsts = readl(hsotg->regs + DSTS);
> - int ep0_mps = 0, ep_mps = 1023;
> + int ep0_mps = 0, ep_mps = 8;
>
> /*
>* This should signal the finish of the enumeration phase
> --
> 2.0.0
Acked-by: Paul Zimmerman
Greg, can you take this for 3.17-final please? Thanks.
--
Paul
--
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 3/3] MAINTAINERS: Add dwc3-st.c file to ARCH/STI architecture
On Wed, Jul 30, 2014 at 04:28:11PM +0100, Peter Griffin wrote: -ENOLOG > Signed-off-by: Peter Griffin > Acked-by: Lee Jones > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 702ca10..269ad3b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1325,6 +1325,7 @@ F: drivers/pinctrl/pinctrl-st.c > F: drivers/media/rc/st_rc.c > F: drivers/i2c/busses/i2c-st.c > F: drivers/tty/serial/st-asc.c > +F: drivers/usb/dwc3/dwc3-st.c also doesn't apply, please rebase on v3.17-rc1. As for the other two patches, I'm reviewing them right now and they apply cleanly, at least. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 2/3] usb: dwc3: dwc3-st: Add st-dwc3 devicetree bindings documentation
On Wed, Jul 30, 2014 at 04:28:10PM +0100, Peter Griffin wrote:
> This patch documents the device tree documentation required for
> the ST usb3 controller glue layer found in STiH407 devices.
>
> Signed-off-by: Giuseppe Cavallaro
> Signed-off-by: Peter Griffin
> Acked-by: Lee Jones
> ---
> Documentation/devicetree/bindings/usb/dwc3-st.txt | 69
> +++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/dwc3-st.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3-st.txt
> b/Documentation/devicetree/bindings/usb/dwc3-st.txt
> new file mode 100644
> index 000..de3fea3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/dwc3-st.txt
> @@ -0,0 +1,69 @@
> +ST DWC3 glue logic
> +
> +This file documents the parameters for the dwc3-st driver.
> +This driver controls the glue logic used to configure the dwc3 core on
> +STiH407 based platforms.
> +
> +Required properties:
> + - compatible: must be "st,stih407-dwc3"
> + - reg : glue logic base address and USB syscfg ctrl register
> offset
> + - reg-names : should be "reg-glue" and "syscfg-reg"
> + - st,syscon : should be phandle to system configuration node which
> + encompasses the glue registers
> + - resets: list of phandle and reset specifier pairs. There should be
> two entries, one
> + for the powerdown and softreset lines of the usb3 IP
> + - reset-names : list of reset signal names. Names should be
> "powerdown" and "softreset"
> +See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
> +See: Documentation/devicetree/bindings/reset/reset.txt
> +
> + - #address-cells, #size-cells : should be '1' if the device has sub-nodes
> + with 'reg' property
> +
> + - pinctl-names : A pinctrl state named "default" must be defined
> +See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
> +
> + - pinctrl-0 : Pin control group
> +See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
> +
> + - ranges: allows valid 1:1 translation between child's address space and
> + parent's address space
> +
> +Sub-nodes:
> +The dwc3 core should be added as subnode to ST DWC3 glue as shown in the
> +example below. The DT binding details of dwc3 can be found in:
> +Documentation/devicetree/bindings/usb/dwc3.txt
> +
> +NB: The dr_mode property described in [1] is NOT optional for this driver,
> as the default value
> +is "otg", which isn't supported by this SoC. Valid dr_mode values for
> dwc3-st are either "host"
> +or "device".
> +
> +[1] Documentation/devicetree/bindings/usb/generic.txt
> +
> +Example:
> +
> +st_dwc3: dwc3@8f94000 {
> + status = "disabled";
> + compatible = "st,stih407-dwc3";
> + reg = <0x08f94000 0x1000>, <0x110 0x4>;
> + reg-names = "reg-glue", "syscfg-reg";
> + st,syscfg = <&syscfg_core>;
> + resets = <&powerdown STIH407_USB3_POWERDOWN>;
> + <&softreset STIH407_MIPHY2_SOFTRESET>;
> + reset-names = "powerdown",
> + "softreset";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usb3>;
> + ranges;
> +
> + dwc3: dwc3@990 {
> + compatible = "snps,dwc3";
> + reg = <0x0990 0x10>;
> + interrupts = ;
> + dr_mode = "host"
> + usb-phy = <&usb3_phy>;
> + phy-names = "usb2-phy";
> + phys= <&usb2_picophy2>;
why are you using different binding for usb2 and usb3 phys ? Why can't
you just:
phys-names = "usb2-phy", "usb3-phy";
phys= <&usb2_picophy2>, <&usb3_phy>;
??
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi,
On Wed, Jul 30, 2014 at 04:28:09PM +0100, Peter Griffin wrote:
> This patch adds the ST glue logic to manage the DWC3 HC
> on STiH407 SoC family. It manages the powerdown signal,
> and configures the internal glue logic and syscfg registers.
>
> Signed-off-by: Giuseppe Cavallaro
> Signed-off-by: Peter Griffin
> Acked-by: Lee Jones
> ---
> drivers/usb/dwc3/Kconfig | 9 ++
> drivers/usb/dwc3/Makefile | 1 +
> drivers/usb/dwc3/dwc3-st.c | 336
> +
> 3 files changed, 346 insertions(+)
> create mode 100644 drivers/usb/dwc3/dwc3-st.c
>
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index 8eb996e..6c85c43 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -79,6 +79,15 @@ config USB_DWC3_KEYSTONE
> Support of USB2/3 functionality in TI Keystone2 platforms.
> Say 'Y' or 'M' here if you have one such device
>
> +config USB_DWC3_ST
> + tristate "STMicroelectronics Platforms"
> + depends on ARCH_STI && OF
> + default USB_DWC3_HOST
this seems wrong as USB_DWC3_{HOST,GADGET,DUAL_ROLE} are booleans and
USB_DWC3_ST is a tristate. Better to stick with defaulting to USB_DWC3
instead like all the others.
> + help
> + STMicroelectronics SoCs with one DesignWare Core USB3 IP
> + inside (i.e. STiH407).
> + Say 'Y' or 'M' if you have one such device.
> +
> comment "Debugging features"
>
> config USB_DWC3_DEBUG
> diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
> index 10ac3e7..11c9f54 100644
> --- a/drivers/usb/dwc3/Makefile
> +++ b/drivers/usb/dwc3/Makefile
> @@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o
> obj-$(CONFIG_USB_DWC3_EXYNOS)+= dwc3-exynos.o
> obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
> obj-$(CONFIG_USB_DWC3_KEYSTONE) += dwc3-keystone.o
> +obj-$(CONFIG_USB_DWC3_ST)+= dwc3-st.o
> diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c
> new file mode 100644
> index 000..227698f
> --- /dev/null
> +++ b/drivers/usb/dwc3/dwc3-st.c
> @@ -0,0 +1,336 @@
> +/**
> + * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics
> platforms
> + *
> + * This is a small driver for the dwc3 to provide the glue logic
> + * to configure the controller. Tested on STi platforms.
> + *
> + * Copyright (C) 2014 Stmicroelectronics
> + *
> + * Author: Giuseppe Cavallaro
> + * Contributors: Aymen Bouattay
> + * Peter Griffin
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * Inspired by dwc3-omap.c and dwc3-exynos.c.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "core.h"
> +#include "io.h"
> +
> +/* glue registers */
> +#define CLKRST_CTRL 0x00
> +#define AUX_CLK_EN BIT(0)
> +#define SW_PIPEW_RESET_N BIT(4)
> +#define EXT_CFG_RESET_N BIT(8)
> +/*
> + * 1'b0 : The host controller complies with the xHCI revision 0.96
> + * 1'b1 : The host controller complies with the xHCI revision 1.0
> + */
> +#define XHCI_REVISIONBIT(12)
> +
> +#define USB2_VBUS_MNGMNT_SEL10x2C
> +/*
> + * For all fields in USB2_VBUS_MNGMNT_SEL1
> + * 2’b00 : Override value from Reg 0x30 is selected
> + * 2’b01 : utmiotg_ from usb3_top is selected
> + * 2’b10 : pipew_ from PIPEW instance is selected
> + * 2’b11 : value is 1'b0
> + */
> +#define USB2_VBUS_REG30 0x0
> +#define USB2_VBUS_UTMIOTG0x1
> +#define USB2_VBUS_PIPEW 0x2
> +#define USB2_VBUS_ZERO 0x3
> +
> +#define SEL_OVERRIDE_VBUSVALID(n)(n << 0)
> +#define SEL_OVERRIDE_POWERPRESENT(n) (n << 4)
> +#define SEL_OVERRIDE_BVALID(n) (n << 8)
> +
> +/* Static DRD configuration */
> +#define USB_HOST_DEFAULT_MASK0xffe
> +#define USB_SET_PORT_DEVICE 0x1
> +
> +/**
> + * struct st_dwc3 - dwc3-st driver private structure
> + * @dev: device pointer
> + * @glue_base: ioaddr for the glue registers
> + * @regmap: regmap pointer for getting syscfg
> + * @syscfg_reg_off: usb syscfg control offset
> + * @dr_mode: drd static host/device config
> + * @rstc_pwrdn: rest controller for powerdown signal
> + * @rstc_rst:reset controller for softreset signal
> + */
> +
> +struct st_dwc3 {
> + struct device *dev;
> + void __iomem *glue_base;
> + struct regmap *regmap;
> + int syscfg_reg_off;
> + enum usb_dr_mode dr_mode;
> + struct reset_control *rstc_pwrdn;
> + struct reset_control *rstc_rst;
> +};
> +
> +static inline u32 st_
Re: [PATCH v4] usb: gadget: at91_udc: move prepare clk into process context
Hi, On Fri, Aug 08, 2014 at 11:42:42AM +0200, Ronald Wahl wrote: > Commit 7628083227b6bc4a7e33d7c381d7a4e558424b6b (usb: gadget: at91_udc: > prepare clk before calling enable) added clock preparation in interrupt > context. This is not allowed as it might sleep. Also setting the clock > rate is unsafe to call from there for the same reason. Move clock > preparation and setting clock rate into process context (at91udc_probe). > > Signed-off-by: Ronald Wahl do we need this for the -rc cycle ? Does it need to be backported to stable releases ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/5] usb: phy: samsung: remove old USB PHY code
Hi, On Thu, Aug 14, 2014 at 04:25:22PM +0200, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series removes the old Samsung USB PHY drivers that > got replaced by the new ones using the generic PHY layer. > > Depends on: > - next-20140813 branch of linux-next kernel this thread seems to have died, what do I need to do with these patches? Are we deleting the phy drivers or not ? Please rebase on v3.17-rc1 and resend with all Acks in place. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/7] usb-phy: samsung: Cleanup the unused drivers
Hi, On Thu, Aug 14, 2014 at 07:53:53PM +0530, Vivek Gautam wrote: > - This series is based on 'usb-next' branch. > > Now that we have support for USB PHY controllers for Exynos SoC series, > we are free to remove the older usb-phy support. > In the process, we are removing the entire phy-samsung-usb3 driver, and > besides that all support for Exynos4x and Exynos5 from phy-samsung-usb2 > driver. > > We have also removed the older USB-PHY support from ehci-exynos and > ohci-exynos > since those drivers now can use newer GENERIC-PHYs, and don't need the older > USB-PHYs and related code anymore. These patches for ohci-exynos and > ehci-exynos > now replaces the older sent patch for phy sequence cleanup for them.[1] > > I have build-tested this series for exynos_defconfig and s3c64xx_defconfig, > and have tested the EHCI and OHCI operations on smdk5250 board, but > have not tested the actual working due to unavailability of S3C64XX > board. So can someone please help me testing this series. > > [1] https://lkml.org/lkml/2014/8/5/142 > > Vivek Gautam (7): > usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver > usb-phy: samsung-usb2: Remove support for Exynos5250 > usb-phy: samsung-usb2: Remove support for Exynos4X12 > usb-phy: samsung-usb2: Remove support for Exynos4210 > usb-phy: samsung-usb2: Clean up to leave only S3C64XX support > usb: host: ehci-exynos: Remove unnecessary usb-phy support > usb: host: ohci-exynos: Remove unnecessary usb-phy support some of these patches are still RFC, can you resend without RFC and all proper Acks in place ? Also rebased on top of v3.17-rc1. thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: composite: dequeue cdev->req before free it in composite_dev_cleanup
On Tue, Jul 15, 2014 at 10:07:40PM +0800, Li Jun wrote:
> This patch try to dequeue the cdev->req to guarantee the request is not queued
> before free it.
>
> Signed-off-by: Li Jun
> ---
> drivers/usb/gadget/composite.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
> index f801519..6935a82 100644
> --- a/drivers/usb/gadget/composite.c
> +++ b/drivers/usb/gadget/composite.c
> @@ -1956,6 +1956,7 @@ void composite_dev_cleanup(struct usb_composite_dev
> *cdev)
> }
> if (cdev->req) {
> kfree(cdev->req->buf);
> + usb_ep_dequeue(cdev->gadget->ep0, cdev->req);
it's best to dequeue the request before freeing its buffer.
--
balbi
signature.asc
Description: Digital signature
Re: usb_gadget_state_work not triggering sysfs_notify
Hi,
On Mon, Jul 07, 2014 at 12:53:45PM +0200, Michael Grzeschik wrote:
> Hi,
>
> I am currently working with an udc where the userspace should react on
> plugging
which udc is that ? which kernel version are you using ?
> and unplugging of the device. The layers used trigger the
> usb_gadget_state_work
> as expected, but the sysfs_notify never cross the userspace layer.
>
>
> static void usb_gadget_state_work(struct work_struct *work)
> {
> struct usb_gadget *gadget = work_to_gadget(work);
>
> sysfs_notify(&gadget->dev.kobj, NULL, "state");
> }
>
> When I create my own device attribute and call this function on it, everything
> works fine and my test application reacts on the event.
>
> I thing we mess with an regression where the attribute is not found in
huh ? Can you clarify what you mean here ?
> sysfs_notify. I see that kernfs_find_and_get is returning NULL and therefor
> never call kernfs_notify.
this would mean 'state' attribute was not found. Are you sure you can
find it on sysfs manually ?
> Does anybody know what could be the matter here?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
On Wed, Jul 23, 2014 at 03:33:23PM +0100, Peter Griffin wrote: > > > > > + reset_control_assert(dwc3_data->rstc_pwrdn); > > > > > + > > > > > + pinctrl_pm_select_sleep_state(dev); > > > > pinctrl will select sleep and default states automatically for you. > > I've left this in v3, as greping around I couldn't see how that could > happen automatically. > > Also I just double checked with linusw on irc who confirmed that the > only state which is ever auto-selected is "default". All other states, > as well as going back to default state need to be explicitly called. > > Hope thats ok. yeah, that's fine. Thanks :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: composite: dequeue cdev->req before free it in composite_dev_cleanup
On Wed, 20 Aug 2014, Felipe Balbi wrote:
> On Tue, Jul 15, 2014 at 10:07:40PM +0800, Li Jun wrote:
> > This patch try to dequeue the cdev->req to guarantee the request is not
> > queued
> > before free it.
> >
> > Signed-off-by: Li Jun
> > ---
> > drivers/usb/gadget/composite.c |1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
> > index f801519..6935a82 100644
> > --- a/drivers/usb/gadget/composite.c
> > +++ b/drivers/usb/gadget/composite.c
> > @@ -1956,6 +1956,7 @@ void composite_dev_cleanup(struct usb_composite_dev
> > *cdev)
> > }
> > if (cdev->req) {
> > kfree(cdev->req->buf);
> > + usb_ep_dequeue(cdev->gadget->ep0, cdev->req);
>
> it's best to dequeue the request before freeing its buffer.
In fact, it's best to wait for the request's completion routine to be
called before freeing the buffer. The hardware can access the buffer's
memory at any time before the completion routine runs.
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] usb: gadget: composite: dequeue cdev->req before free it in composite_dev_cleanup
On Wed, Aug 20, 2014 at 03:06:28PM -0400, Alan Stern wrote:
> On Wed, 20 Aug 2014, Felipe Balbi wrote:
>
> > On Tue, Jul 15, 2014 at 10:07:40PM +0800, Li Jun wrote:
> > > This patch try to dequeue the cdev->req to guarantee the request is not
> > > queued
> > > before free it.
> > >
> > > Signed-off-by: Li Jun
> > > ---
> > > drivers/usb/gadget/composite.c |1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/usb/gadget/composite.c
> > > b/drivers/usb/gadget/composite.c
> > > index f801519..6935a82 100644
> > > --- a/drivers/usb/gadget/composite.c
> > > +++ b/drivers/usb/gadget/composite.c
> > > @@ -1956,6 +1956,7 @@ void composite_dev_cleanup(struct usb_composite_dev
> > > *cdev)
> > > }
> > > if (cdev->req) {
> > > kfree(cdev->req->buf);
> > > + usb_ep_dequeue(cdev->gadget->ep0, cdev->req);
> >
> > it's best to dequeue the request before freeing its buffer.
>
> In fact, it's best to wait for the request's completion routine to be
> called before freeing the buffer. The hardware can access the buffer's
> memory at any time before the completion routine runs.
dequeue should cause the transfer to be cancelled and given back.
There's a slight possible race window because we release the controller
lock in order to call gadget driver's ->complete().
Other than that, it should be fine. No ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH V4 0/2] usb: gadget: zero: Add support for interrupt EP
Hi, On Mon, Jul 21, 2014 at 12:16:36PM +0530, Amit Virdi wrote: > This patchset adds support for interrupt EP and the corresponding test cases > to > gadget zero. The code has been rebased and tested on Kernel v3.15-rc5 this doesn't apply anymore. Can you rebase on my testing/next (or v3.17-rc1) thanks -- balbi signature.asc Description: Digital signature
Re: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN
On Tue, 19 Aug 2014, Christoph Hellwig wrote: > On Thu, Aug 07, 2014 at 11:58:37AM -0400, Alan Stern wrote: > > > On Wed, Aug 06, 2014 at 04:02:22PM -0400, Alan Stern wrote: > > > > > I doubt either of them forces users to hack up flags for these cases. > > > > > > > > Why was this change needed in the first place? There's no explanation > > > > in the patch itself. > > > > > > Which chance? The one to not support SG_FLAG_LUN_INHIBIT? > > > > No, the patch that started this Bugzilla entry. Tiziano says it is > > needed in order to send vendor-specific commands that use the LUN bits > > in CDB[1]. > > Yes, I'd really like to know the exact scenario. What kind of command > is this and who sends it? I don't know what the command is, but Tiziano is sending it via the SCSI-generic (sg) interface. In the meantime, I have made a little progress with Windows. It turns out there are two reasons my earlier test didn't work: I didn't bother to set up a valid serial number for the test device, and Windows wants to see the serial number. Windows wants at least one of the logical units to be removable. After those issues were fixed, the host did recognize both logical units. I tested with two devices, one reporting an ANSI SCSI level of 0 and the other 2. In both cases, Windows 7 does _not_ stick the LUN value into the high bits of CDB[1]. This suggests that we shouldn't be doing that either, for USB mass-storage devices. But I'm reluctant to change it because of the possibility of regressions, not to mention the fact that it would violate the SCSI spec. Suggestions? 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] usb: gadget: composite: dequeue cdev->req before free it in composite_dev_cleanup
On Wed, 20 Aug 2014, Felipe Balbi wrote:
> > > > --- a/drivers/usb/gadget/composite.c
> > > > +++ b/drivers/usb/gadget/composite.c
> > > > @@ -1956,6 +1956,7 @@ void composite_dev_cleanup(struct
> > > > usb_composite_dev *cdev)
> > > > }
> > > > if (cdev->req) {
> > > > kfree(cdev->req->buf);
> > > > + usb_ep_dequeue(cdev->gadget->ep0, cdev->req);
> > >
> > > it's best to dequeue the request before freeing its buffer.
> >
> > In fact, it's best to wait for the request's completion routine to be
> > called before freeing the buffer. The hardware can access the buffer's
> > memory at any time before the completion routine runs.
>
> dequeue should cause the transfer to be cancelled and given back.
> There's a slight possible race window because we release the controller
> lock in order to call gadget driver's ->complete().
>
> Other than that, it should be fine. No ?
Dequeue causes the transfer to be cancelled and given back, yes. But
usb_ep_dequeue() is allowed to return before those things happen.
It depends on the implementation; in general the only way to know that
the hardware has finished aborting or completing the request is to wait
until the completion routine is called.
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/3] usb: add support for Diolan DLN-2 devices
On Wednesday 20 August 2014, Daniel Baluta wrote: > From: Octavian Purdila > > This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO > Master Adapter DLN-2. Details about the device can be found here: > > https://www.diolan.com/i2c/i2c_interface.html. > > Information about the USB protocol can be found in the Programmer's > Reference Manual [1], see section 1.7. > > Because the hardware has a single transmit endpoint and a single > receive endpoint the communication between the various DLN2 drivers > and the hardware will be muxed/demuxed by this driver. > > The functional DLN2 drivers (i2c, GPIO, etc.) will have to register > themselves as DLN2 modules in order to send or receive data. > > Each DLN2 module will be identified by the handle field within the DLN2 > message header. If a DLN2 module issues multiple commands in parallel > they will be identified by the echo counter field in the message header. > > The DLN2 modules can use the dln2_transfer() function to issue a > command and wait for its response. They can also use an asynchronous > mode of operation, in which case a receive callback function is going > to be notified when messages for a specific handle are received. > > Because the hardware reserves handle 0 for GPIO events, the driver > also reserves handle 0. It will be allocated to a DLN2 module only if > it is explicitly requested. > > [1] https://www.diolan.com/downloads/dln-api-manual.pdf > > Signed-off-by: Octavian Purdila After a very brief review of the driver, I think this would be better handled as an MFD driver in drivers/mfd that creates child devices and has the high-level drivers get registered as platform_driver. Arnd -- 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: Transient USB disconnects
On Wed, 20 Aug 2014, David Laight wrote:
> > On Tue, 19 Aug 2014, David Laight wrote:
> >
> > > From: Alan Stern
> > >
> > > > Since the device is plugged into a hub, the hub knows about the
> > > > disconnection. But it can't inform the kernel until the host
> > > > controller polls it, which occurs at 128-ms intervals.
> > >
> > > That rather explains the delay in the error reporting.
> > > I rather hoped it would be a little quicker.
> > > I presume the kernel can't force a status poll after a URB failure?
> >
> > I suppose that could be added. It doesn't seem to be terribly
> > important. Rapidly detecting disconnects is a separate issue from too
> > much noise in the log when a disconnect occurs.
>
> Indeed...
> There isn't much point tracing URB failures if the reason is a disconnect.
> I know the logic would get contorted, but it would be more user-friendly
> to only report the disconnect - even if it isn't checked until after the
> first reset fail.
The error messages could be changed to debug messages. But maybe we
can do a better job of reducing them. Does the patch below help?
> > > The usbhid driver (at least the version I'm using ubuntu 3.11.0-26)
> > > is a bit noisy on usb unplugs.
> >
> > Yeah, there's an error message every time a reset fails (a call to
> > hid_err() in drivers/hid/usbhid/hid-core.c:hid_reset()). The resets
> > are supposed to occur at increasing intervals; I'm not sure if that's
> > working as intended. It might be preferable not to retry at all after
> > a reset fails.
>
> I think they are at increasing intervals, but still quite frequent.
No, the intervals are not increasing. And the reason is because
despite what the messages say, the system isn't trying to reset the HID
device. Instead it's trying to clear an endpoint halt.
The same subroutine in the usbhid driver is used for both clearing
halts and performing resets. If anything goes wrong, it logs the
"can't reset device" message, regardless of what it was actually
trying to do.
Unlike resets, the driver does not use increasing delays for clearing
halts. In fact, it doesn't delay at all; it tries to clear the halt as
soon as possible.
It looks like we need to be a little more careful here. When a
clear-halt fails, we should reset instead of attempting to resume
normal operations. That's what this patch tries to do.
> > It doesn't help that your device has two HID interfaces, which means
> > you get double the number of log message.
>
> Actually I got some devices plugged elsewhere.
> The smsc hub could easily have keyboard, mouse and its I2C/serial
> active (all are hid) as well as the ethernet.
> My keyboard has two input devices (NFI why, it doesn't have any unusual keys).
I think the second input device is used for some of the normal keys, or
maybe for the LEDs. Lots of keyboards do this.
> > > Possibly it has been build with one too many DEBUG options enabled.
> > > Most of the usb stack has dynamic debug enabled.
> >
> > Dynamic debugging doesn't do anything about error messages, though.
>
> Yes, they seem to have missed the trick of having a few levels of
> messages - so that annoying error messages can be disabled, or debug
> and diagnostic (normal path) messages enabled in bulk.
What do you mean? We _do_ have levels of messages -- that's the
difference between a debug message and an error message. With dynamic
debugging, debug messages can be enabled in bulk.
Alan Stern
Index: usb-3.16/drivers/hid/usbhid/hid-core.c
===
--- usb-3.16.orig/drivers/hid/usbhid/hid-core.c
+++ usb-3.16/drivers/hid/usbhid/hid-core.c
@@ -116,40 +116,24 @@ static void hid_reset(struct work_struct
struct usbhid_device *usbhid =
container_of(work, struct usbhid_device, reset_work);
struct hid_device *hid = usbhid->hid;
- int rc = 0;
+ int rc;
if (test_bit(HID_CLEAR_HALT, &usbhid->iofl)) {
dev_dbg(&usbhid->intf->dev, "clear halt\n");
rc = usb_clear_halt(hid_to_usb_dev(hid), usbhid->urbin->pipe);
clear_bit(HID_CLEAR_HALT, &usbhid->iofl);
- hid_start_in(hid);
- }
-
- else if (test_bit(HID_RESET_PENDING, &usbhid->iofl)) {
- dev_dbg(&usbhid->intf->dev, "resetting device\n");
- rc = usb_lock_device_for_reset(hid_to_usb_dev(hid),
usbhid->intf);
if (rc == 0) {
- rc = usb_reset_device(hid_to_usb_dev(hid));
- usb_unlock_device(hid_to_usb_dev(hid));
+ hid_start_in(hid);
+ } else {
+ dev_dbg(&usbhid->intf->dev,
+ "clear-halt failed: %d\n", rc);
+ set_bit(HID_RESET_PENDING, &usbhid->iofl);
}
- clear_bit(HID_RESET_PENDING, &usbhid->iofl);
}
- switch (rc) {
- cas
Re: [PATCH 3/3] xhci: rework cycle bit checking for new dequeue pointers
On 08/19/2014 08:17 AM, Mathias Nyman wrote:
> When we manually need to move the TR dequeue pointer we need to set the
> correct cycle bit as well. Previously we used the trb pointer from the
> last event received as a base, but this was changed in
> commit 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer")
> to use the dequeue pointer from the endpoint context instead
>
> It turns out some Asmedia controllers advance the dequeue pointer
> stored in the endpoint context past the event triggering TRB, and
> this messed up the way the cycle bit was calculated.
>
> Instead of adding a quirk or complicating the already hard to follow cycle bit
> code, the whole cycle bit calculation is now simplified and adapted to handle
> event and endpoint context dequeue pointer differences.
>
> Fixes: 1f81b6d22a59 ("usb: xhci: Prefer endpoint context dequeue pointer")
> Reported-by: Maciej Puzio
> Reported-by: Evan Langlois
> Reviewed-by: Julius Werner
> Tested-by: Maciej Puzio
> Tested-by: Evan Langlois
> Signed-off-by: Mathias Nyman
> Cc: sta...@vger.kernel.org
> ---
> drivers/usb/host/xhci-ring.c | 101
> +--
> drivers/usb/host/xhci.c | 3 ++
> 2 files changed, 42 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index ac8cf23..abed30b 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -364,32 +364,6 @@ static void ring_doorbell_for_active_rings(struct
> xhci_hcd *xhci,
> }
> }
>
> -/*
> - * Find the segment that trb is in. Start searching in start_seg.
> - * If we must move past a segment that has a link TRB with a toggle cycle
> state
> - * bit set, then we will toggle the value pointed at by cycle_state.
> - */
> -static struct xhci_segment *find_trb_seg(
> - struct xhci_segment *start_seg,
> - union xhci_trb *trb, int *cycle_state)
> -{
> - struct xhci_segment *cur_seg = start_seg;
> - struct xhci_generic_trb *generic_trb;
> -
> - while (cur_seg->trbs > trb ||
> - &cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) {
> - generic_trb = &cur_seg->trbs[TRBS_PER_SEGMENT - 1].generic;
> - if (generic_trb->field[3] & cpu_to_le32(LINK_TOGGLE))
> - *cycle_state ^= 0x1;
> - cur_seg = cur_seg->next;
> - if (cur_seg == start_seg)
> - /* Looped over the entire list. Oops! */
> - return NULL;
> - }
> - return cur_seg;
> -}
> -
> -
> static struct xhci_ring *xhci_triad_to_transfer_ring(struct xhci_hcd *xhci,
> unsigned int slot_id, unsigned int ep_index,
> unsigned int stream_id)
> @@ -459,9 +433,12 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
> struct xhci_virt_device *dev = xhci->devs[slot_id];
> struct xhci_virt_ep *ep = &dev->eps[ep_index];
> struct xhci_ring *ep_ring;
> - struct xhci_generic_trb *trb;
> + struct xhci_segment *new_seg;
> + union xhci_trb *new_deq;
> dma_addr_t addr;
> u64 hw_dequeue;
> + bool cycle_found = false;
> + bool td_last_trb_found = false;
>
> ep_ring = xhci_triad_to_transfer_ring(xhci, slot_id,
> ep_index, stream_id);
> @@ -486,45 +463,45 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
> hw_dequeue = le64_to_cpu(ep_ctx->deq);
> }
>
> - /* Find virtual address and segment of hardware dequeue pointer */
> - state->new_deq_seg = ep_ring->deq_seg;
> - state->new_deq_ptr = ep_ring->dequeue;
> - while (xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr)
> - != (dma_addr_t)(hw_dequeue & ~0xf)) {
> - next_trb(xhci, ep_ring, &state->new_deq_seg,
> - &state->new_deq_ptr);
> - if (state->new_deq_ptr == ep_ring->dequeue) {
> - WARN_ON(1);
> - return;
> - }
> - }
> + new_seg = ep_ring->deq_seg;
> + new_deq = ep_ring->dequeue;
> + state->new_cycle_state = hw_dequeue & 0x1;
> +
> /*
> - * Find cycle state for last_trb, starting at old cycle state of
> - * hw_dequeue. If there is only one segment ring, find_trb_seg() will
> - * return immediately and cannot toggle the cycle state if this search
> - * wraps around, so add one more toggle manually in that case.
> + * We want to find the pointer, segment and cycle state of the new trb
> + * (the one after current TD's last_trb). We know the cycle state at
> + * hw_dequeue, so walk the ring until both hw_dequeue and last_trb are
> + * found.
>*/
> - state->new_cycle_state = hw_dequeue & 0x1;
> - if (ep_ring->first_seg == ep_ring->first_seg->next &&
> - cur_td->last_trb < state->new_deq_ptr)
> - state->new_cycle_sta
Re: Problem with USB-to-SATA adapters
On Wed, 2014-08-20 at 16:18 -0400, Dale R. Worley wrote: > I don't know if this is the correct place for this problem, but you > people can probably tell me the correct place. linux-usb can probably also help (cc'd). > I have two "USB to SATA adapter" dongles. In general, they work fine. > However I've discovered that one of them handles large (1 TB and > above) drives correctly and one does not. In particular, when I use > the unsuccessful one, neither fdisk nor gdisk reports the disk size > correctly, and the kernel does not read the partition table. > > More confusingly, both dongles work correctly with large disks on > Windows 7 Professional. > > Both of the following cases are when a 3.0 TB drive is attached. > > The successful device has the "Diablo" brand. The most interesting > messages in the log when I plug in the USB are (the complete message > set is appended below): > > Aug 18 21:56:53 hobgoblin kernel: [ 294.229462] usb 2-1.3: New USB device > found, idVendor=152d, idProduct=2338 > Aug 18 21:56:53 hobgoblin kernel: [ 294.229475] usb 2-1.3: New USB device > strings: Mfr=1, Product=2, SerialNumber=5 > Aug 18 21:56:53 hobgoblin kernel: [ 294.229482] usb 2-1.3: Product: USB to > ATA/ATAPI bridge > Aug 18 21:56:53 hobgoblin kernel: [ 294.229488] usb 2-1.3: Manufacturer: > JMicron > Aug 18 21:56:53 hobgoblin kernel: [ 294.229495] usb 2-1.3: SerialNumber: > 01D91CC4 > Aug 18 21:56:54 hobgoblin kernel: [ 295.236576] sd 7:0:0:0: [sdb] Very big > device. Trying to use READ CAPACITY(16). > Aug 18 21:56:54 hobgoblin kernel: [ 295.236955] sd 7:0:0:0: [sdb] 5860533168 > 512-byte logical blocks: (3.00 TB/2.72 TiB) > > The unsuccessful device has the "Ez-Connect" brand. The most > interesting messages in the log when I plug in the USB are (the > complete message set is appended below): > > Aug 18 21:54:06 hobgoblin kernel: [ 127.674374] usb 2-2: new high-speed USB > device number 4 using ehci-pci > Aug 18 21:54:06 hobgoblin kernel: [ 127.791128] usb 2-2: New USB device > found, idVendor=05e3, idProduct=0718 > Aug 18 21:54:06 hobgoblin kernel: [ 127.791135] usb 2-2: New USB device > strings: Mfr=0, Product=1, SerialNumber=2 > Aug 18 21:54:06 hobgoblin kernel: [ 127.791138] usb 2-2: Product: USB Storage > Aug 18 21:54:06 hobgoblin kernel: [ 127.791142] usb 2-2: SerialNumber: > 0033 > Aug 18 21:54:07 hobgoblin kernel: [ 128.847269] sd 6:0:0:0: [sdb] 1565565872 > 512-byte logical blocks: (801 GB/746 GiB) So the basic problem here seems to be that this adapter has wrapped the INQUIRY response instead of giving us the the conventional response that means my device is too big. This could be because the processing engine on the card doesn't understand 16 byte commands (which are required for addressing capacity > 2TB) or it could just be a firmware SCSI emulator mistake. The best way of telling might be to use the SG_IO interface to send a read capacity 16. sg_readcap --16 should be able to do this. If you get a sensible response, chances are we should just quirk this device to apply RC16 first. If something goes wrong, it's likely unfixably broken for devices > 2TB James > Dale > > -- > For the Diablo adapter: > > Aug 18 21:56:53 hobgoblin kernel: [ 294.153343] usb 2-1.3: new high-speed > USB device number 5 using ehci-pci > Aug 18 21:56:53 hobgoblin kernel: [ 294.229462] usb 2-1.3: New USB device > found, idVendor=152d, idProduct=2338 > Aug 18 21:56:53 hobgoblin kernel: [ 294.229475] usb 2-1.3: New USB device > strings: Mfr=1, Product=2, SerialNumber=5 > Aug 18 21:56:53 hobgoblin kernel: [ 294.229482] usb 2-1.3: Product: USB to > ATA/ATAPI bridge > Aug 18 21:56:53 hobgoblin kernel: [ 294.229488] usb 2-1.3: Manufacturer: > JMicron > Aug 18 21:56:53 hobgoblin kernel: [ 294.229495] usb 2-1.3: SerialNumber: > 01D91CC4 > Aug 18 21:56:53 hobgoblin kernel: [ 294.231159] usb-storage 2-1.3:1.0: USB > Mass Storage device detected > Aug 18 21:56:53 hobgoblin kernel: [ 294.233951] scsi7 : usb-storage 2-1.3:1.0 > Aug 18 21:56:53 hobgoblin mtp-probe: checking bus 2, device 5: > "/sys/devices/pci:00/:00:1d.7/usb2/2-1/2-1.3" > Aug 18 21:56:53 hobgoblin mtp-probe: bus: 2, device: 5 was not an MTP device > Aug 18 21:56:54 hobgoblin kernel: [ 295.235735] scsi 7:0:0:0: Direct-Access >WDC WD30 EZRX-00SPEB0 PQ: 0 ANSI: 5 > Aug 18 21:56:54 hobgoblin kernel: [ 295.236209] sd 7:0:0:0: Attached scsi > generic sg2 type 0 > Aug 18 21:56:54 hobgoblin kernel: [ 295.236576] sd 7:0:0:0: [sdb] Very big > device. Trying to use READ CAPACITY(16). > Aug 18 21:56:54 hobgoblin kernel: [ 295.236955] sd 7:0:0:0: [sdb] 5860533168 > 512-byte logical blocks: (3.00 TB/2.72 TiB) > Aug 18 21:56:54 hobgoblin kernel: [ 295.237957] sd 7:0:0:0: [sdb] Write > Protect is off > Aug 18 21:56:54 hobgoblin kernel: [ 295.238957] sd 7:0:0:0: [sdb] No Caching > mode page found > Aug 18 21:56:5
Re: [PATCH] usb: gadget: composite: dequeue cdev->req before free it in composite_dev_cleanup
On Wed, Aug 20, 2014 at 03:18:47PM -0400, Alan Stern wrote:
> On Wed, 20 Aug 2014, Felipe Balbi wrote:
>
> > > > > --- a/drivers/usb/gadget/composite.c
> > > > > +++ b/drivers/usb/gadget/composite.c
> > > > > @@ -1956,6 +1956,7 @@ void composite_dev_cleanup(struct
> > > > > usb_composite_dev *cdev)
> > > > > }
> > > > > if (cdev->req) {
> > > > > kfree(cdev->req->buf);
> > > > > + usb_ep_dequeue(cdev->gadget->ep0, cdev->req);
> > > >
> > > > it's best to dequeue the request before freeing its buffer.
> > >
> > > In fact, it's best to wait for the request's completion routine to be
> > > called before freeing the buffer. The hardware can access the buffer's
> > > memory at any time before the completion routine runs.
> >
> > dequeue should cause the transfer to be cancelled and given back.
> > There's a slight possible race window because we release the controller
> > lock in order to call gadget driver's ->complete().
> >
The dp has already been pulled down and the flush pending FIFO buffer
has finished, so the controller should not try to access memory buffer
after that.
> > Other than that, it should be fine. No ?
>
> Dequeue causes the transfer to be cancelled and given back, yes. But
> usb_ep_dequeue() is allowed to return before those things happen.
>
If usb_ep_dequeue is returned before doing any flush and cancel
transfer, it means there is no request on the queue, we don't need
to cancel any requests.
Felipe's suggestion is safe way, we can have a patch for it.
> It depends on the implementation; in general the only way to know that
> the hardware has finished aborting or completing the request is to wait
> until the completion routine is called.
>
> Alan Stern
>
--
Best Regards,
Peter Chen
--
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 net-next 3/4] r8152: remove clear_bp function
: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com] > Sent: Wednesday, August 20, 2014 8:01 PM > To: Hayes Wang; net...@vger.kernel.org > Cc: nic_swsd; linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org > Subject: Re: [PATCH net-next 3/4] r8152: remove clear_bp function [...] > > r8152b_disable_aldps(tp); > > > > - rtl_clear_bp(tp); > > > > Why leave 2 empty lines? One is enough. The next patch would use another fucntion at the same location. I skip removing the empty line and re-adding it again. Is that better to do so? I would resend the patches if the answer is yes. Best Regards, Hayes -- 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 3/5] usb: phy: samsung: remove old USB 2.0 PHY driver
Hi Tomasz and Bartlomiej, On Mon, Aug 18, 2014 at 4:52 PM, Tomasz Figa wrote: > On 18.08.2014 13:02, Bartlomiej Zolnierkiewicz wrote: >> On Thursday, August 14, 2014 08:07:40 PM Vivek Gautam wrote: >>> On Thursday, August 14, 2014 7:55 PM, Bartlomiej Zolnierkiewicz >>> wrote >> >>> There's one thing that I would want to comment here, since we don't have any >>> new usb-phy driver for S3C64XX, >>> so we can't simply remove this entire driver. >>> I have posted my patch-series [1], which does cleanup while keeping the >>> support for S3C64XX. >> >> AFAIK S3C64XX code from drivers/usb/phy/phy-samsung-usb2.c has >> never been used as this platform still uses its own code from >> arch/arm/mach-s3c64xx/setup-usb-phy.c (there are no users in >> the kernel tree of either s3c64xx-usb2phy platform device or >> "samsung,s3c64xx-usb2phy" DT compatible) . Therefore I think >> that the entire drivers/usb/phy/phy-samsung-usb2.c driver >> should be removed (somebody with the hardware can as well add >> S3C64XX support to the new drivers/phy/phy-samsung-usb2.c >> driver and port the platform to use it). >> > > I agree with removal of this driver. As Bart said, it is not used for > S3C64xx at all. The platform was supposed to be moved to this driver, > but that never happened. In fact, I already have a patch adding support > for S3C64xx to the new driver. Cool then, lets remove this driver completely and use the new generic PHY based driver once that comes (from Tomasz). I shall drop the patches for cleaning up the usb-phy drivers from my series. -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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 0/5] usb: phy: samsung: remove old USB PHY code
On Thu, Aug 14, 2014 at 7:55 PM, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series removes the old Samsung USB PHY drivers that > got replaced by the new ones using the generic PHY layer. > > Depends on: > - next-20140813 branch of linux-next kernel > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > > > Bartlomiej Zolnierkiewicz (5): > ARM: dts: remove old USB2 PHY node hook for Arndale > ARM: dts: remove old USB2 PHY node for Exynos5250 > usb: phy: samsung: remove old USB 2.0 PHY driver > usb: phy: samsung: remove old USB 3.0 PHY driver > usb: phy: samsung: remove old common USB PHY code Reviewed-by: Vivek Gautam -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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 0/7] usb-phy: samsung: Cleanup the unused drivers
Hi Felipe, On Wed, Aug 20, 2014 at 11:44 PM, Felipe Balbi wrote: > Hi, > > On Thu, Aug 14, 2014 at 07:53:53PM +0530, Vivek Gautam wrote: >> - This series is based on 'usb-next' branch. >> >> Now that we have support for USB PHY controllers for Exynos SoC series, >> we are free to remove the older usb-phy support. >> In the process, we are removing the entire phy-samsung-usb3 driver, and >> besides that all support for Exynos4x and Exynos5 from phy-samsung-usb2 >> driver. >> >> We have also removed the older USB-PHY support from ehci-exynos and >> ohci-exynos >> since those drivers now can use newer GENERIC-PHYs, and don't need the older >> USB-PHYs and related code anymore. These patches for ohci-exynos and >> ehci-exynos >> now replaces the older sent patch for phy sequence cleanup for them.[1] >> >> I have build-tested this series for exynos_defconfig and s3c64xx_defconfig, >> and have tested the EHCI and OHCI operations on smdk5250 board, but >> have not tested the actual working due to unavailability of S3C64XX >> board. So can someone please help me testing this series. >> >> [1] https://lkml.org/lkml/2014/8/5/142 >> >> Vivek Gautam (7): >> usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver >> usb-phy: samsung-usb2: Remove support for Exynos5250 >> usb-phy: samsung-usb2: Remove support for Exynos4X12 >> usb-phy: samsung-usb2: Remove support for Exynos4210 >> usb-phy: samsung-usb2: Clean up to leave only S3C64XX support >> usb: host: ehci-exynos: Remove unnecessary usb-phy support >> usb: host: ohci-exynos: Remove unnecessary usb-phy support > > some of these patches are still RFC, can you resend without RFC and all > proper Acks in place ? Also rebased on top of v3.17-rc1. As per the discussion in thread [1], i am dropping the [Patch 1/7] till [Patch 5/7] since these are part of the cleanup series by Bart: [PATCH 0/5] usb: phy: samsung: remove old USB PHY code; and will send out the rebased remaining two patches with Alan's Ack. [1] https://lkml.org/lkml/2014/8/21/11 -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- 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 3/5] usb: phy: samsung: remove old USB 2.0 PHY driver
On Thursday, August 21, 2014 1:31 PM, Vivek Gautam wrote: > On Mon, Aug 18, 2014 at 4:52 PM, Tomasz Figa wrote: > > On 18.08.2014 13:02, Bartlomiej Zolnierkiewicz wrote: > >> On Thursday, August 14, 2014 08:07:40 PM Vivek Gautam wrote: > >>> On Thursday, August 14, 2014 7:55 PM, Bartlomiej Zolnierkiewicz > >>> wrote > >> > >>> There's one thing that I would want to comment here, since we don't have > >>> any > >>> new usb-phy driver for S3C64XX, > >>> so we can't simply remove this entire driver. > >>> I have posted my patch-series [1], which does cleanup while keeping the > >>> support for S3C64XX. > >> > >> AFAIK S3C64XX code from drivers/usb/phy/phy-samsung-usb2.c has > >> never been used as this platform still uses its own code from > >> arch/arm/mach-s3c64xx/setup-usb-phy.c (there are no users in > >> the kernel tree of either s3c64xx-usb2phy platform device or > >> "samsung,s3c64xx-usb2phy" DT compatible) . Therefore I think > >> that the entire drivers/usb/phy/phy-samsung-usb2.c driver > >> should be removed (somebody with the hardware can as well add > >> S3C64XX support to the new drivers/phy/phy-samsung-usb2.c > >> driver and port the platform to use it). > >> > > > > I agree with removal of this driver. As Bart said, it is not used for > > S3C64xx at all. The platform was supposed to be moved to this driver, > > but that never happened. Yes, right. As far as I know, you're right. > > In fact, I already have a patch adding support > > for S3C64xx to the new driver. Good! > > Cool then, lets remove this driver completely and use the new generic > PHY based driver > once that comes (from Tomasz). I agree with this opinion. > > I shall drop the patches for cleaning up the usb-phy drivers from my series. Best regards, Jingoo Han -- 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 0/5] usb: phy: samsung: remove old USB PHY code
On Thursday, August 21, 2014 1:34 PM, Vivek Gautam wrote: > On Thu, Aug 14, 2014 at 7:55 PM, Bartlomiej Zolnierkiewicz > wrote: > > Hi, > > > > This patch series removes the old Samsung USB PHY drivers that > > got replaced by the new ones using the generic PHY layer. > > > > Depends on: > > - next-20140813 branch of linux-next kernel > > > > Best regards, > > -- > > Bartlomiej Zolnierkiewicz > > Samsung R&D Institute Poland > > Samsung Electronics > > > > > > Bartlomiej Zolnierkiewicz (5): > > ARM: dts: remove old USB2 PHY node hook for Arndale > > ARM: dts: remove old USB2 PHY node for Exynos5250 > > usb: phy: samsung: remove old USB 2.0 PHY driver > > usb: phy: samsung: remove old USB 3.0 PHY driver > > usb: phy: samsung: remove old common USB PHY code > > Reviewed-by: Vivek Gautam Reviewed-by: Jingoo Han Best regards, Jingoo Han -- 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] usb: gadget: serial: replace {V,}DBG macro with dev_{v,}dbg
Replace the VDBG and DBG macro with the kernels "proper" debug macros
(dev_vdbg and dev_dbg) in f_acm.c, f_obex.c & f_serial.c
Signed-off-by: Richard Leitner
---
v2: - rebased on Linux v3.17-rc1
- fixed some PARENTHESIS_ALIGNMENT checkpatch.pl warnings
---
drivers/usb/gadget/function/f_acm.c| 49 ++--
drivers/usb/gadget/function/f_obex.c | 28 +++---
drivers/usb/gadget/function/f_serial.c | 19 +++--
3 files changed, 56 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/gadget/function/f_acm.c
b/drivers/usb/gadget/function/f_acm.c
index ab1065a..6da4685 100644
--- a/drivers/usb/gadget/function/f_acm.c
+++ b/drivers/usb/gadget/function/f_acm.c
@@ -313,15 +313,15 @@ static void acm_complete_set_line_coding(struct usb_ep
*ep,
struct usb_composite_dev *cdev = acm->port.func.config->cdev;
if (req->status != 0) {
- DBG(cdev, "acm ttyGS%d completion, err %d\n",
- acm->port_num, req->status);
+ dev_dbg(&cdev->gadget->dev, "acm ttyGS%d completion, err %d\n",
+ acm->port_num, req->status);
return;
}
/* normal completion */
if (req->actual != sizeof(acm->port_line_coding)) {
- DBG(cdev, "acm ttyGS%d short resp, len %d\n",
- acm->port_num, req->actual);
+ dev_dbg(&cdev->gadget->dev, "acm ttyGS%d short resp, len %d\n",
+ acm->port_num, req->actual);
usb_ep_set_halt(ep);
} else {
struct usb_cdc_line_coding *value = req->buf;
@@ -397,14 +397,16 @@ static int acm_setup(struct usb_function *f, const struct
usb_ctrlrequest *ctrl)
default:
invalid:
- VDBG(cdev, "invalid control req%02x.%02x v%04x i%04x l%d\n",
- ctrl->bRequestType, ctrl->bRequest,
- w_value, w_index, w_length);
+ dev_vdbg(&cdev->gadget->dev,
+"invalid control req%02x.%02x v%04x i%04x l%d\n",
+ctrl->bRequestType, ctrl->bRequest,
+w_value, w_index, w_length);
}
/* respond with data transfer or status phase? */
if (value >= 0) {
- DBG(cdev, "acm ttyGS%d req%02x.%02x v%04x i%04x l%d\n",
+ dev_dbg(&cdev->gadget->dev,
+ "acm ttyGS%d req%02x.%02x v%04x i%04x l%d\n",
acm->port_num, ctrl->bRequestType, ctrl->bRequest,
w_value, w_index, w_length);
req->zero = 0;
@@ -428,10 +430,12 @@ static int acm_set_alt(struct usb_function *f, unsigned
intf, unsigned alt)
if (intf == acm->ctrl_id) {
if (acm->notify->driver_data) {
- VDBG(cdev, "reset acm control interface %d\n", intf);
+ dev_vdbg(&cdev->gadget->dev,
+"reset acm control interface %d\n", intf);
usb_ep_disable(acm->notify);
} else {
- VDBG(cdev, "init acm ctrl interface %d\n", intf);
+ dev_vdbg(&cdev->gadget->dev,
+"init acm ctrl interface %d\n", intf);
if (config_ep_by_speed(cdev->gadget, f, acm->notify))
return -EINVAL;
}
@@ -440,11 +444,13 @@ static int acm_set_alt(struct usb_function *f, unsigned
intf, unsigned alt)
} else if (intf == acm->data_id) {
if (acm->port.in->driver_data) {
- DBG(cdev, "reset acm ttyGS%d\n", acm->port_num);
+ dev_dbg(&cdev->gadget->dev,
+ "reset acm ttyGS%d\n", acm->port_num);
gserial_disconnect(&acm->port);
}
if (!acm->port.in->desc || !acm->port.out->desc) {
- DBG(cdev, "activate acm ttyGS%d\n", acm->port_num);
+ dev_dbg(&cdev->gadget->dev,
+ "activate acm ttyGS%d\n", acm->port_num);
if (config_ep_by_speed(cdev->gadget, f,
acm->port.in) ||
config_ep_by_speed(cdev->gadget, f,
@@ -467,7 +473,7 @@ static void acm_disable(struct usb_function *f)
struct f_acm*acm = func_to_acm(f);
struct usb_composite_dev *cdev = f->config->cdev;
- DBG(cdev, "acm ttyGS%d deactivated\n", acm->port_num);
+ dev_dbg(&cdev->gadget->dev, "acm ttyGS%d deactivated\n", acm->port_num);
gserial_disconnect(&acm->port);
usb_ep_disable(acm->notify);
acm->notify->driver_data = NULL;
@@ -537,8 +543,8 @@ static int acm_notify_serial_state(struct f_acm *acm)
spin_lock(&acm->lock);
if (acm->notify_req) {
-
Re: [PATCH v2] usb: phy: msm: Make phy_reset clk and reset line optional.
Thanks Felipe, On 20/08/14 16:57, Felipe Balbi wrote: On Thu, Jul 17, 2014 at 09:16:40PM +0100, Srinivas Kandagatla wrote: This patch makes the phy reset clk and reset line optional as this clk is not available on boards like IFC6410 with APQ8064. phy-reset clk is only used as argument to the mach level callbacks, so this patch adds condition before clk_get calls so that the driver wouldn't fail on SOCs which do not have this support. Signed-off-by: Srinivas Kandagatla --- Hi Felipe, With this new patch now the error message is only printed if the SOC actually supports the phy reset clk, for SOCs like APQ8064 where there is no phy reset clock or the callback which takes it there is no point in doing a clk_get call in the first place. doesn't apply. Please rebase on top of v3.17-rc1 this is because a previous version of the same patch got applied. Anyway I will rebase this patch and send v3. thanks, srini -- 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] usb: phy: msm: Make phy_reset clk and reset line optional.
This patch makes the phy reset clk and reset line optional as this clk
is not available on boards like IFC6410 with APQ8064.
phy-reset clk is only used as argument to the mach level callbacks, so
this patch adds condition before clk_get calls so that the driver
wouldn't fail on SOCs which do not have this support.
Signed-off-by: Srinivas Kandagatla
---
Hi Felipe,
With this new patch now the error message is only printed if the SOC actually
supports
the phy reset clk, for SOCs like APQ8064 where there is no phy reset clock or
the callback which takes it there is no point in doing a clk_get call in the
first place.
Changes since v2:
- rebased patch on top of v3.17-rc1
Thanks,
srini
drivers/usb/phy/phy-msm-usb.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index e4108ee..7f6aa32 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -281,7 +281,7 @@ static int msm_otg_phy_clk_reset(struct msm_otg *motg)
{
int ret = 0;
- if (motg->pdata->phy_clk_reset && motg->phy_reset_clk)
+ if (motg->pdata->phy_clk_reset)
ret = motg->pdata->phy_clk_reset(motg->phy_reset_clk);
else if (motg->phy_rst)
ret = reset_control_reset(motg->phy_rst);
@@ -1554,11 +1554,14 @@ static int msm_otg_probe(struct platform_device *pdev)
phy = &motg->phy;
phy->dev = &pdev->dev;
- motg->phy_reset_clk = devm_clk_get(&pdev->dev,
+ if (motg->pdata->phy_clk_reset) {
+ motg->phy_reset_clk = devm_clk_get(&pdev->dev,
np ? "phy" : "usb_phy_clk");
- if (IS_ERR(motg->phy_reset_clk)) {
- dev_err(&pdev->dev, "failed to get usb_phy_clk\n");
- motg->phy_reset_clk = NULL;
+
+ if (IS_ERR(motg->phy_reset_clk)) {
+ dev_err(&pdev->dev, "failed to get usb_phy_clk\n");
+ return PTR_ERR(motg->phy_reset_clk);
+ }
}
motg->clk = devm_clk_get(&pdev->dev, np ? "core" : "usb_hs_clk");
--
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
Re: [PATCH v4 2/2] usb: gadget: Add xilinx usb2 device support
Hi Daniel,
On Tue, Aug 19, 2014 at 3:26 PM, Daniel Mack wrote:
> Hi,
>
> On 07/22/2014 11:08 AM, Subbaraya Sundeep Bhatta wrote:
>> This patch adds xilinx usb2 device driver support
>
> Add some more information here, please. Copying the text from the
> Kconfig option is already a good start.
>
>> drivers/usb/gadget/Kconfig | 14 +
>> drivers/usb/gadget/Makefile |1 +
>> drivers/usb/gadget/udc-xilinx.c | 2261
>> +++
>> 3 files changed, 2276 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/usb/gadget/udc-xilinx.c
>
> As your driver has a DT binding, you have to describe it in
> Documentation/devicetree/bindings.
>
>> --- a/drivers/usb/gadget/Kconfig
>> +++ b/drivers/usb/gadget/Kconfig
>> @@ -459,6 +459,20 @@ config USB_EG20T
>> ML7213/ML7831 is companion chip for Intel Atom E6xx series.
>> ML7213/ML7831 is completely compatible for Intel EG20T PCH.
>>
>> +config USB_GADGET_XILINX
>> + tristate "Xilinx USB Driver"
>> + depends on COMPILE_TEST
>
> Why would you depend on that?
Felipe asked to make this since this is USB soft IP driver and its
dependencies have tendency to grow.
Currently tested on arm and microblaze architectures.
>
> Also, your code uses device tree functions unconditionally, which is
> fine, but it must hence depend on 'OF'.
Ok will add OF along with COMPILE_TEST
>
>> +struct xusb_ep {
>> + struct usb_ep ep_usb;
>> + struct list_head queue;
>> + struct xusb_udc *udc;
>> + const struct usb_endpoint_descriptor *desc;
>> + u32 rambase;
>> + u32 offset;
>> + char name[4];
>> + u16 epnumber;
>> + u16 maxpacket;
>> + u16 buffer0count;
>> + u16 buffer1count;
>> + u8 buffer0ready;
>> + u8 buffer1ready;
>> + u8 eptype;
>> + u8 curbufnum;
>> + u8 is_in;
>> + u8 is_iso;
>
> Some of those could probably become booleans.
Ok
>
>> +struct xusb_udc {
>> + struct usb_gadget gadget;
>> + struct xusb_ep ep[8];
>> + struct usb_gadget_driver *driver;
>> + struct usb_ctrlrequest setup;
>> + struct xusb_req *req;
>> + struct device *dev;
>> + u32 usb_state;
>> + u32 remote_wkp;
>> + u32 setupseqtx;
>> + u32 setupseqrx;
>> + void __iomem *base_address;
>> + spinlock_t lock;
>> + bool dma_enabled;
>> +
>> + unsigned int (*read_fn)(void __iomem *);
>> + void (*write_fn)(void __iomem *, u32, u32);
>> +};
>> +
>> +/* Endpoint buffer start addresses in the core */
>> +static u32 rambase[8] = { 0x22, 0x1000, 0x1100, 0x1200, 0x1300, 0x1400,
>> 0x1500,
>> + 0x1600 };
>
> As stated by Peter, indenting such lines to match the position of the
> line before makes such code much prettier and more readable. It's also
> done in the majority of drivers.
>
> This counts for many locations in your code.
Ok
>
>> +/* Control endpoint configuration.*/
>> +static const struct usb_endpoint_descriptor config_bulk_out_desc = {
>> + .bLength= USB_DT_ENDPOINT_SIZE,
>> + .bDescriptorType= USB_DT_ENDPOINT,
>> + .bEndpointAddress = USB_DIR_OUT,
>> + .bmAttributes = USB_ENDPOINT_XFER_BULK,
>> + .wMaxPacketSize = cpu_to_le16(64),
>
> Why not use EP0_MAX_PACKET here?
Ok
>
>> +static void xudc_wrstatus(struct xusb_udc *udc)
>> +{
>> + struct xusb_ep *ep0 = &udc->ep[XUSB_EP_NUMBER_ZERO];
>> + u32 epcfgreg;
>> +
>> + epcfgreg = udc->read_fn(udc->base_address + ep0->offset)|
>> + XUSB_EP_CFG_DATA_TOGGLE_MASK;
>> + udc->write_fn(udc->base_address, ep0->offset, epcfgreg);
>> + udc->write_fn(udc->base_address, ep0->offset +
>> XUSB_EP_BUF0COUNT_OFFSET,
>> + 0);
>
> Just a nit, but renaming 'base_address' to something like 'base' or
> 'addr' would help you get around or maximum line constraint here and in
> some other places.
Ok i will do this
>
>> +static int xudc_dma_send(struct xusb_ep *ep, struct xusb_req *req,
>> + u8 *buffer, u32 length)
>> +{
>> + u32 *eprambase;
>> + dma_addr_t src;
>> + dma_addr_t dst;
>> + int ret;
>> + struct xusb_udc *udc = ep->udc;
>> +
>> + src = req->usb_req.dma + req->usb_req.actual;
>> + if (req->usb_req.length)
>> + dma_sync_single_for_device(udc->dev, src,
>> + length, DMA_TO_DEVICE);
>> + if (!ep->curbufnum && !ep->buffer0ready) {
>> + /* Get the Buffer address and copy the transmit data.*/
>> + eprambase = (u32 __force *)(udc->base_address +
>> + ep->rambase);
>> + dst = virt_to_phys(eprambase);
>> + udc->write_fn(udc->base_address, ep->offset +
>> + XUSB_EP_BUF0COUNT_OFFSET, length);
>> + udc->write_fn(udc->base_address, XUSB_DMA_CONTROL_OFFSET,
>> + XUSB_DMA_BRR_CTRL | (1 << ep->epnumber));
>> +
[PATCH] usb: gadget: serial: remove PREFIX macro
Remove the ttyGS PREFIX macro from u_serial.c and replace all occurences with
the hardcoded ttyGS string.
This macro was mostly used in a few debug/warning messages and a lot of
hardcoded ttyGS existed beneath. It may have been used for renaming the
tty, but if done so most debug messages would have ignored this.
Due to the fact the usage of this PREFIX in all debug calls would have
resulted in a hard to read/grep code it is removed completely.
Signed-off-by: Richard Leitner
---
changes from RFC to PATCH:
- rebased on v3.17-rc1
- fixed some PARENTHESIS_ALIGNMENT checkpatch.pl warnings
---
drivers/usb/gadget/function/u_serial.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index ad0aca8..491082a 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -55,11 +55,8 @@
* for a telephone or fax link. And ttyGS2 might be something that just
* needs a simple byte stream interface for some messaging protocol that
* is managed in userspace ... OBEX, PTP, and MTP have been mentioned.
- */
-
-#define PREFIX "ttyGS"
-
-/*
+ *
+ *
* gserial is the lifecycle interface, used by USB functions
* gs_port is the I/O nexus, used by the tty driver
* tty_struct links to the tty/filesystem framework
@@ -385,9 +382,9 @@ __acquires(&port->port_lock)
list_del(&req->list);
req->zero = (gs_buf_data_avail(&port->port_write_buf) == 0);
- pr_vdebug(PREFIX "%d: tx len=%d, 0x%02x 0x%02x 0x%02x ...\n",
- port->port_num, len, *((u8 *)req->buf),
- *((u8 *)req->buf+1), *((u8 *)req->buf+2));
+ pr_vdebug("ttyGS%d: tx len=%d, 0x%02x 0x%02x 0x%02x ...\n",
+ port->port_num, len, *((u8 *)req->buf),
+ *((u8 *)req->buf+1), *((u8 *)req->buf+2));
/* Drop lock while we call out of driver; completions
* could be issued while we do so. Disconnection may
@@ -503,13 +500,13 @@ static void gs_rx_push(unsigned long _port)
switch (req->status) {
case -ESHUTDOWN:
disconnect = true;
- pr_vdebug(PREFIX "%d: shutdown\n", port->port_num);
+ pr_vdebug("ttyGS%d: shutdown\n", port->port_num);
break;
default:
/* presumably a transient fault */
- pr_warning(PREFIX "%d: unexpected RX status %d\n",
- port->port_num, req->status);
+ pr_warn("ttyGS%d: unexpected RX status %d\n",
+ port->port_num, req->status);
/* FALLTHROUGH */
case 0:
/* normal completion */
@@ -537,9 +534,8 @@ static void gs_rx_push(unsigned long _port)
if (count != size) {
/* stop pushing; TTY layer can't handle more */
port->n_read += count;
- pr_vdebug(PREFIX "%d: rx block %d/%d\n",
- port->port_num,
- count, req->actual);
+ pr_vdebug("ttyGS%d: rx block %d/%d\n",
+ port->port_num, count, req->actual);
break;
}
port->n_read = 0;
@@ -569,7 +565,7 @@ static void gs_rx_push(unsigned long _port)
if (do_push)
tasklet_schedule(&port->push);
else
- pr_warning(PREFIX "%d: RX not scheduled?\n",
+ pr_warn("ttyGS%d: RX not scheduled?\n",
port->port_num);
}
}
@@ -985,7 +981,7 @@ static void gs_unthrottle(struct tty_struct *tty)
* read queue backs up enough we'll be NAKing OUT packets.
*/
tasklet_schedule(&port->push);
- pr_vdebug(PREFIX "%d: unthrottle\n", port->port_num);
+ pr_vdebug("ttyGS%d: unthrottle\n", port->port_num);
}
spin_unlock_irqrestore(&port->port_lock, flags);
}
@@ -1295,7 +1291,7 @@ static int userial_init(void)
return -ENOMEM;
gs_tty_driver->driver_name = "g_serial";
- gs_tty_driver->name = PREFIX;
+ gs_tty_driver->name = "ttyGS";
/* uses dynamically assigned dev_t values */
gs_tty_driver->type = TTY_DRIVER_TYPE_SERIAL;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.k
