Re: [PATCH v5 4/5] typec: tcpm: Represent source supply through power_supply
On 03/20/2018 07:33 AM, Adam Thomson wrote:
This commit adds a power_supply class instance to represent a
PD source's voltage and current properties. This provides an
interface for reading these properties from user-space or other
drivers.
For PPS enabled Sources, this also provides write access to set
the current and voltage and allows for swapping between standard
PDO and PPS APDO.
As this represents a superset of the information provided in the
fusb302 driver, the power_supply instance in that code is removed
as part of this change, so reverting the commit titled
'typec: tcpm: Represent source supply through power_supply class'
Signed-off-by: Adam Thomson
---
drivers/usb/typec/Kconfig | 1 +
drivers/usb/typec/fusb302/Kconfig | 2 +-
drivers/usb/typec/fusb302/fusb302.c | 63 +-
drivers/usb/typec/tcpm.c| 242 +++-
4 files changed, 245 insertions(+), 63 deletions(-)
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index bcb2744..1ef606d 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -48,6 +48,7 @@ if TYPEC
config TYPEC_TCPM
tristate "USB Type-C Port Controller Manager"
depends on USB
+ select POWER_SUPPLY
help
The Type-C Port Controller Manager provides a USB PD and USB Type-C
state machine for use with Type-C Port Controllers.
diff --git a/drivers/usb/typec/fusb302/Kconfig
b/drivers/usb/typec/fusb302/Kconfig
index 48a4f2f..fce099f 100644
--- a/drivers/usb/typec/fusb302/Kconfig
+++ b/drivers/usb/typec/fusb302/Kconfig
@@ -1,6 +1,6 @@
config TYPEC_FUSB302
tristate "Fairchild FUSB302 Type-C chip driver"
- depends on I2C && POWER_SUPPLY
+ depends on I2C
help
The Fairchild FUSB302 Type-C chip driver that works with
Type-C Port Controller Manager to provide USB PD and USB
diff --git a/drivers/usb/typec/fusb302/fusb302.c
b/drivers/usb/typec/fusb302/fusb302.c
index 06794c0..6a8f279 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -99,11 +98,6 @@ struct fusb302_chip {
/* lock for sharing chip states */
struct mutex lock;
- /* psy + psy status */
- struct power_supply *psy;
- u32 current_limit;
- u32 supply_voltage;
-
/* chip status */
enum toggling_mode toggling_mode;
enum src_current_status src_current_status;
@@ -861,13 +855,11 @@ static int tcpm_set_vbus(struct tcpc_dev *dev, bool on,
bool charge)
chip->vbus_on = on;
fusb302_log(chip, "vbus := %s", on ? "On" : "Off");
}
- if (chip->charge_on == charge) {
+ if (chip->charge_on == charge)
fusb302_log(chip, "charge is already %s",
charge ? "On" : "Off");
- } else {
+ else
chip->charge_on = charge;
- power_supply_changed(chip->psy);
- }
done:
mutex_unlock(&chip->lock);
@@ -883,11 +875,6 @@ static int tcpm_set_current_limit(struct tcpc_dev *dev,
u32 max_ma, u32 mv)
fusb302_log(chip, "current limit: %d ma, %d mv (not implemented)",
max_ma, mv);
- chip->supply_voltage = mv;
- chip->current_limit = max_ma;
-
- power_supply_changed(chip->psy);
-
return 0;
}
@@ -1686,43 +1673,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static int fusb302_psy_get_property(struct power_supply *psy,
- enum power_supply_property psp,
- union power_supply_propval *val)
-{
- struct fusb302_chip *chip = power_supply_get_drvdata(psy);
-
- switch (psp) {
- case POWER_SUPPLY_PROP_ONLINE:
- val->intval = chip->charge_on;
- break;
- case POWER_SUPPLY_PROP_VOLTAGE_NOW:
- val->intval = chip->supply_voltage * 1000; /* mV -> µV */
- break;
- case POWER_SUPPLY_PROP_CURRENT_MAX:
- val->intval = chip->current_limit * 1000; /* mA -> µA */
- break;
- default:
- return -ENODATA;
- }
-
- return 0;
-}
-
-static enum power_supply_property fusb302_psy_properties[] = {
- POWER_SUPPLY_PROP_ONLINE,
- POWER_SUPPLY_PROP_VOLTAGE_NOW,
- POWER_SUPPLY_PROP_CURRENT_MAX,
-};
-
-static const struct power_supply_desc fusb302_psy_desc = {
- .name = "fusb302-typec-source",
- .type = POWER_SUPPLY_TYPE_USB_TYPE_C,
- .properties = fusb302_psy_properties,
- .num_properties = ARRAY_SIZE(fusb302_psy_properties),
- .get_property = fusb302_psy_get_property,
-};
-
static int init_gpio(struct fusb302_chip *chip)
{
struct device_node *node;
@@
Re: [PATCH v5 3/5] power: supply: Add 'usb_type' property and supporting code
On 03/20/2018 07:33 AM, Adam Thomson wrote:
This commit adds the 'usb_type' property to represent USB supplies
which can report a number of different types based on a connection
event.
Examples of this already exist in drivers whereby the existing 'type'
property is updated, based on an event, to represent what was
connected (e.g. USB, USB_DCP, USB_ACA, ...). Current implementations
however don't show all supported connectable types, so this knowledge
has to be exlicitly known for each driver that supports this.
The 'usb_type' property is intended to fill this void and show users
all possible USB types supported by a driver. The property, when read,
shows all available types for the driver, and the one currently chosen
is highlighted/bracketed. It is expected that the 'type' property
would then just show the top-level type 'USB', and this would be
static.
Currently the 'usb_type' enum contains all of the USB variant types
that exist for the 'type' enum at this time, and in addition has
SDP and PPS types. The mirroring is intentional so as to not impact
existing usage of the 'type' property.
Signed-off-by: Adam Thomson
Acked-by: Heikki Krogerus
Reviewed-by: Sebastian Reichel
---
Documentation/ABI/testing/sysfs-class-power | 12 +++
drivers/power/supply/power_supply_sysfs.c | 50 +
include/linux/power_supply.h| 16 +
3 files changed, 78 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power
b/Documentation/ABI/testing/sysfs-class-power
index e046566..5e23e22 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -409,6 +409,18 @@ Description:
Access: Read
Valid values: Represented in 1/10 Degrees Celsius
+What: /sys/class/power_supply//usb_type
+Date: March 2018
+Contact: linux...@vger.kernel.org
+Description:
+ Reports what type of USB connection is currently active for
+ the supply, for example it can show if USB-PD capable source
+ is attached.
+
+ Access: Read-Only
+ Valid values: "Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
+ "PD_DRP", "PD_PPS", "BrickID"
+
What: /sys/class/power_supply//voltage_max
Date: January 2008
Contact: linux...@vger.kernel.org
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index 5204f11..b68def4 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -46,6 +46,11 @@
"USB_PD", "USB_PD_DRP", "BrickID"
};
+static const char * const power_supply_usb_type_text[] = {
+ "Unknown", "SDP", "DCP", "CDP", "ACA", "C",
+ "PD", "PD_DRP", "PD_PPS", "BrickID"
+};
+
static const char * const power_supply_status_text[] = {
"Unknown", "Charging", "Discharging", "Not charging", "Full"
};
@@ -73,6 +78,46 @@
"Unknown", "System", "Device"
};
+static ssize_t power_supply_show_usb_type(struct device *dev,
+ enum power_supply_usb_type *usb_types,
+ ssize_t num_usb_types,
+ union power_supply_propval *value,
+ char *buf)
+{
+ enum power_supply_usb_type usb_type;
+ ssize_t count = 0;
+ bool match = false;
+ int i;
+
+ if ((!usb_types) || (num_usb_types <= 0)) {
Unnecessary ( )
+ dev_warn(dev, "driver has no valid connected types\n");
Are those warnings useful or do they just clog the log ? Either case, if that
happens,
wouldn't it be better to detect the situation during registration and abort ?
+ return -ENODATA;
+ }
+
+ for (i = 0; i < num_usb_types; ++i) {
+ usb_type = usb_types[i];
+
+ if (value->intval == usb_type) {
+ count += sprintf(buf + count, "[%s] ",
+power_supply_usb_type_text[usb_type]);
+ match = true;
+ } else {
+ count += sprintf(buf + count, "%s ",
+power_supply_usb_type_text[usb_type]);
+ }
+ }
+
+ if (!match) {
+ dev_warn(dev, "driver reporting unsupported connected type\n");
+ return -EINVAL;
+ }
+
+ if (count)
+ buf[count - 1] = '\n';
+
+ return count;
+}
+
static ssize_t power_supply_show_property(struct device *dev,
struct device_attribute *attr,
char *buf) {
@@ -115,6 +160,10 @@ static ssize_t power_supply_show_property(struct device
*dev,
else if (off == POWER_SUPPLY_PROP_TYPE)
return sp
Re: [PATCH v5 1/5] typec: tcpm: Add core support for sink side PPS
On 03/20/2018 07:33 AM, Adam Thomson wrote:
This commit adds code to handle requesting of PPS APDOs. Switching
between standard PDOs and APDOs, and re-requesting an APDO to
modify operating voltage/current will be triggered by an
external call into TCPM.
Signed-off-by: Adam Thomson
Acked-by: Heikki Krogerus
---
drivers/usb/typec/tcpm.c | 524 +--
include/linux/usb/pd.h | 4 +-
include/linux/usb/tcpm.h | 2 +-
3 files changed, 513 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 4c0fc54..b4cf1ca 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -47,6 +47,7 @@
S(SNK_DISCOVERY_DEBOUNCE_DONE), \
S(SNK_WAIT_CAPABILITIES), \
S(SNK_NEGOTIATE_CAPABILITIES), \
+ S(SNK_NEGOTIATE_PPS_CAPABILITIES), \
S(SNK_TRANSITION_SINK), \
S(SNK_TRANSITION_SINK_VBUS),\
S(SNK_READY), \
@@ -166,6 +167,16 @@ struct pd_mode_data {
struct typec_altmode_desc altmode_desc[SVID_DISCOVERY_MAX];
};
+struct pd_pps_data {
+ u32 min_volt;
+ u32 max_volt;
+ u32 max_curr;
+ u32 out_volt;
+ u32 op_curr;
+ bool supported;
+ bool active;
+};
+
struct tcpm_port {
struct device *dev;
@@ -233,6 +244,7 @@ struct tcpm_port {
struct completion swap_complete;
int swap_status;
+ unsigned int negotiated_rev;
unsigned int message_id;
unsigned int caps_count;
unsigned int hard_reset_count;
@@ -259,6 +271,7 @@ struct tcpm_port {
unsigned int max_snk_ma;
unsigned int max_snk_mw;
unsigned int operating_snk_mw;
+ bool update_sink_caps;
/* Requested current / voltage */
u32 current_limit;
@@ -275,8 +288,13 @@ struct tcpm_port {
/* VDO to retry if UFP responder replied busy */
u32 vdo_retry;
- /* Alternate mode data */
+ /* PPS */
+ struct pd_pps_data pps_data;
+ struct completion pps_complete;
+ bool pps_pending;
+ int pps_status;
+ /* Alternate mode data */
struct pd_mode_data mode_data;
struct typec_altmode *partner_altmode[SVID_DISCOVERY_MAX];
struct typec_altmode *port_altmode[SVID_DISCOVERY_MAX];
@@ -494,6 +512,16 @@ static void tcpm_log_source_caps(struct tcpm_port *port)
pdo_max_voltage(pdo),
pdo_max_power(pdo));
break;
+ case PDO_TYPE_APDO:
+ if (pdo_apdo_type(pdo) == APDO_TYPE_PPS)
+ scnprintf(msg, sizeof(msg),
+ "%u-%u mV, %u mA",
+ pdo_pps_apdo_min_voltage(pdo),
+ pdo_pps_apdo_max_voltage(pdo),
+ pdo_pps_apdo_max_current(pdo));
+ else
+ strcpy(msg, "undefined APDO");
+ break;
default:
strcpy(msg, "undefined");
break;
@@ -777,11 +805,13 @@ static int tcpm_pd_send_source_caps(struct tcpm_port
*port)
msg.header = PD_HEADER_LE(PD_CTRL_REJECT,
port->pwr_role,
port->data_role,
+ port->negotiated_rev,
port->message_id, 0);
} else {
msg.header = PD_HEADER_LE(PD_DATA_SOURCE_CAP,
port->pwr_role,
port->data_role,
+ port->negotiated_rev,
port->message_id,
port->nr_src_pdo);
}
@@ -802,11 +832,13 @@ static int tcpm_pd_send_sink_caps(struct tcpm_port *port)
msg.header = PD_HEADER_LE(PD_CTRL_REJECT,
port->pwr_role,
port->data_role,
+ port->negotiated_rev,
port->message_id, 0);
} else {
msg.header = PD_HEADER_LE(PD_DATA_SINK_CAP,
port->pwr_role,
port->data_role,
+ port->negotiated_rev,
port->message_id,
port->nr_snk_pdo);
}
@@ -1173,6 +1205,7 @@ static void vdm_run_state_machine(struct tcpm_port *port)
msg.header = PD_HEADER_LE(PD_DATA_VENDOR_DEF,
Re: [PATCH v5 5/5] typec: tcpm: Add support for sink PPS related messages
On 03/20/2018 07:33 AM, Adam Thomson wrote:
This commit adds sink side support for Get_Status, Status,
Get_PPS_Status and PPS_Status handling. As there's the
potential for a partner to respond with Not_Supported,
handling of this message is also added. Sending of
Not_Supported is added to handle messagescreceived but not
yet handled.
Signed-off-by: Adam Thomson
Acked-by: Heikki Krogerus
---
drivers/usb/typec/tcpm.c | 152 ---
1 file changed, 143 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 18ab36f..148db99 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -19,7 +19,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -113,6 +115,11 @@
S(SNK_TRYWAIT_VBUS),\
S(BIST_RX), \
\
+ S(GET_STATUS_SEND), \
+ S(GET_STATUS_SEND_TIMEOUT), \
+ S(GET_PPS_STATUS_SEND), \
+ S(GET_PPS_STATUS_SEND_TIMEOUT), \
+ \
S(ERROR_RECOVERY), \
S(PORT_RESET), \
S(PORT_RESET_WAIT_OFF)
@@ -143,6 +150,7 @@ enum pd_msg_request {
PD_MSG_NONE = 0,
PD_MSG_CTRL_REJECT,
PD_MSG_CTRL_WAIT,
+ PD_MSG_CTRL_NOT_SUPP,
PD_MSG_DATA_SINK_CAP,
PD_MSG_DATA_SOURCE_CAP,
};
@@ -1398,10 +1406,42 @@ static int tcpm_validate_caps(struct tcpm_port *port,
const u32 *pdo,
/*
* PD (data, control) command handling functions
*/
+static inline enum tcpm_state ready_state(struct tcpm_port *port)
+{
+ if (port->pwr_role == TYPEC_SOURCE)
+ return SRC_READY;
+ else
+ return SNK_READY;
+}
static int tcpm_pd_send_control(struct tcpm_port *port,
enum pd_ctrl_msg_type type);
+static void tcpm_handle_alert(struct tcpm_port *port, const __le32 *payload,
+ int cnt)
+{
+ u32 p0 = le32_to_cpu(payload[0]);
+ unsigned int type = usb_pd_ado_type(p0);
+
+ if (!type) {
+ tcpm_log(port, "Alert message received with no type");
+ return;
+ }
+
+ /* Just handling non-battery alerts for now */
+ if (!(type & USB_PD_ADO_TYPE_BATT_STATUS_CHANGE)) {
+ switch (port->state) {
+ case SRC_READY:
+ case SNK_READY:
+ tcpm_set_state(port, GET_STATUS_SEND, 0);
+ break;
+ default:
+ tcpm_queue_message(port, PD_MSG_CTRL_WAIT);
+ break;
+ }
+ }
+}
+
static void tcpm_pd_data_request(struct tcpm_port *port,
const struct pd_message *msg)
{
@@ -1487,6 +1527,14 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
tcpm_set_state(port, BIST_RX, 0);
}
break;
+ case PD_DATA_ALERT:
+ tcpm_handle_alert(port, msg->payload, cnt);
+ break;
+ case PD_DATA_BATT_STATUS:
+ case PD_DATA_GET_COUNTRY_INFO:
+ /* Currently unsupported */
+ tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+ break;
default:
tcpm_log(port, "Unhandled data message type %#x", type);
break;
@@ -1569,6 +1617,7 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
break;
case PD_CTRL_REJECT:
case PD_CTRL_WAIT:
+ case PD_CTRL_NOT_SUPP:
switch (port->state) {
case SNK_NEGOTIATE_CAPABILITIES:
/* USB PD specification, Figure 8-43 */
@@ -1688,12 +1737,84 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
break;
}
break;
+ case PD_CTRL_GET_SOURCE_CAP_EXT:
+ case PD_CTRL_GET_STATUS:
+ case PD_CTRL_FR_SWAP:
+ case PD_CTRL_GET_PPS_STATUS:
+ case PD_CTRL_GET_COUNTRY_CODES:
+ /* Currently not supported */
+ tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+ break;
default:
tcpm_log(port, "Unhandled ctrl message type %#x", type);
break;
}
}
+static void tcpm_pd_ext_msg_request(struct tcpm_port *port,
+ const struct pd_message *msg)
+{
+ enum pd_ext_msg_type type = pd_header_type_le(msg->header);
+ unsigned int data_size =
pd_ext_header_data_size_le(msg->ext_msg.header);
+ u8 *data;
+
+ if (!(msg->ext_msg.header && PD_EXT_HDR_CHUNKED)) {
+ tcpm_log(port, "Unchunked extended messages unsupported");
+
[PATCH] usbip: tools: usbipd: exclude exported devices from exportable device list
usbipd includes exported devices in response to exportable device list.
Exclude exported devices from exportable device list to avoid:
- import requests for devices that are exported only to fail the request.
- revealing devices that are imported by a client to another client.
Signed-off-by: Shuah Khan
---
tools/usb/usbip/src/usbipd.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/tools/usb/usbip/src/usbipd.c b/tools/usb/usbip/src/usbipd.c
index f8ff735eb100..32864c52942d 100644
--- a/tools/usb/usbip/src/usbipd.c
+++ b/tools/usb/usbip/src/usbipd.c
@@ -175,10 +175,21 @@ static int send_reply_devlist(int connfd)
struct list_head *j;
int rc, i;
+ /*
+* Exclude devices that are already exported to a client from
+* the exportable device list to avoid:
+* - import requests for devices that are exported only to
+*fail the request.
+* - revealing devices that are imported by a client to
+*another client.
+*/
+
reply.ndev = 0;
/* number of exported devices */
list_for_each(j, &driver->edev_list) {
- reply.ndev += 1;
+ edev = list_entry(j, struct usbip_exported_device, node);
+ if (edev->status != SDEV_ST_USED)
+ reply.ndev += 1;
}
info("exportable devices: %d", reply.ndev);
@@ -197,6 +208,9 @@ static int send_reply_devlist(int connfd)
list_for_each(j, &driver->edev_list) {
edev = list_entry(j, struct usbip_exported_device, node);
+ if (edev->status == SDEV_ST_USED)
+ continue;
+
dump_usb_device(&edev->udev);
memcpy(&pdu_udev, &edev->udev, sizeof(pdu_udev));
usbip_net_pack_usb_device(1, &pdu_udev);
--
2.14.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: About patchwork for linux-usb
> > > > At some situations, we may need to save reviewing patches from > > > > web, but I can't find linux-usb at > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fp > > > atchwork.k > > > > ernel.org%2F&data=02%7C01%7Cpeter.chen%40nxp.com%7Cbef6ada7885641ed5 > > > > bf408d58b131139%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6365 > > > > 67836369109099&sdata=w8dVZjbsb%2BrboggllBzJbdkxR6r7BQHOEtf7tQ5mCPE% > > > 3D&reserved=0, any there any patchworks for linux-usb mailist at > > > Internet? > Thanks. > > > > > > I do not know of any, as I do not use patchwork, sorry. If you feel > > > that we should add it to patchwork.kernel.org, that can easily be done. > > > > > > thanks, > > > > > > > Some may would like to test the reviewing patches, but they do not > > have the tool like mutt to save patches, it is useful for them. It will be > > great we > would do that, thanks. > > I've asked for it to be included. > > But really, you should use a good email client :) > Thanks, Greg. Company IT policies have changed recently, we are requesting mutt (imap supported) for development. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASMedia SATA Bridge not enumerating without quirk
Well, still, my two cents here, is it really that if you have UAS in a
module and you don't load it but connect an UAS capable device, this
device is not enumerated rather than downgraded to usb-storage?
2018-03-21 19:10 GMT+01:00 Mike Lothian :
> So this is a brown paper bag moment, I don't use usb-uas on my laptop,
> so the kernel always does the right thing (I've enabled it now I know
> about it)
>
> The router has usb-uas compiled as a module, but didn't have it
> installed, it's not one of the default ones it seems
>
> After installing kmod-usb-storage-uas everything kicked into life
>
> Sorry for the noise
>
> On 21 March 2018 at 17:55, Mike Lothian wrote:
>> Lastly here's the lsusb -v and dmesg from 4.9.87 on the router without
>> the quirk added
>>
>> On 21 March 2018 at 17:50, Mike Lothian wrote:
>>> Also here's the kernel config for the router, it's now 4.9.87
>>>
>>>
>>>
>>> On 21 March 2018 at 17:23, Menion wrote:
Yes that was the point.
Curious that the device worked fine in 17.01.4 and not in snapshot,
but in 17.01.4 do you remember if it went in UAS or USB-STORAGE mode?
I cannot answer here, but I am wondering if it is possible that if the
kernel is compiled without UAS support, then a device showing UASP
capability won't get enumerated at all instead of being downgraded to
usb-storage.
2018-03-21 18:19 GMT+01:00 Mike Lothian :
> Sorry I'm not sure what you mean by that, would you like the output of
> lsusb -v before and after the quirk is added? And again from my
> laptop?
>
> I'd like to point the device worked fine when running a 4.4 kernel on
> LEDE 17.01.4
>
> On 21 March 2018 at 17:10, Menion wrote:
>> Then it is so strange, it is completely dead from USB host perspective
>> in UASP mode
>> What lsusb shows when it is attached in UASP mode?
>> Can you test it with some "regular" host with USB 3.0, like a PC?
>>
>> 2018-03-21 18:07 GMT+01:00 Mike Lothian :
>>> Sorry, yes that was me disconnecting the device and reconnecting it,
>>> just to confirm that it was the quirk that was fixing things (I might
>>> not have connected it into the same port)
>>>
>>> I am changing the quirks in the modules config and reattaching,
>>> modprobe on this device doesn't seem to let me specify options
>>>
>>> It's a USB3 caddy that has its own power supply, that you can put any
>>> SATA hard disk into, I currently have a 1.5TB drive in it.
>>>
>>> On 21 March 2018 at 17:00, Menion wrote:
I see a disconnect from port 4:1 of some un-enumerated device then
connect to port 2:1 with UAS blacklist:
[ 281.814757] usb 4-1: USB disconnect, device number 2
[ 283.418292] usb 2-1: new SuperSpeed USB device number 2 using
xhci-hcd
[ 482.153319] usb 2-1: USB disconnect, device number 2
[ 484.250856] usb 2-1: UAS is blacklisted for this device, using
usb-storage instead
[ 484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid
55aa: c0
[ 484.264432] scsi host1: usb-storage 2-1:1.0
Are you peraphs changing the quirks in the modules config and reattach
the device?
Anyhow I see some strange reset from the USB host. What is this
device? Perhaps some self-powered external HDD?
2018-03-21 17:56 GMT+01:00 Mike Lothian :
> It had both, as did my follow up, the follow up should be more clear
> though
>
> On 21 March 2018 at 16:45, Menion wrote:
>> You sent the dmesg with quirks :u enabled
>> We need the one without quirks :u, when the device takes UAS driver
>> Bye
>>
>> 2018-03-21 17:41 GMT+01:00 Mike Lothian :
>>> Hi
>>>
>>> Please find attached my dmesg
>>>
>>> Cheers
>>>
>>> Mike
>>>
>>> On 21 March 2018 at 16:12, Oliver Neukum wrote:
Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
> > I'm guessing it doesn't quite match up with the rules already
> > in place
> > in uas-detect.h
>
> That device has a quirk already as a "normal" usb-storage device.
> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add
> quirk
> for mandatory READ_CAPACITY_16")
That should cause different symptoms.
> > Looks like it's an ASM1053 that can't do UAS
>
> No, it's not a UAS device, is someone trying to recycle device
> ids to do
> different things now? That's not good :(
The second interface looks like UAS though. The second interface
>
[FaceCam 1000X]uvcvideo 3-2.3:1.0: Entity type for entity Processing 2 was not initialized!
Hello, Open report in launchpad.net https://bugs.launchpad.net/bugs/1757509 Kernel Version: Ubuntu 4.15.0-13.14-generic 4.15.10 dmesg: [20147.228136] uvcvideo 3-2.3:1.0: Entity type for entity Processing 2 was not initialized! [20147.228146] uvcvideo 3-2.3:1.0: Entity type for entity Extension 6 was not initialized! [20147.228153] uvcvideo 3-2.3:1.0: Entity type for entity Camera 1 was not initialized! [20147.228445] input: FaceCam 1000X: FaceCam 1000X as /devices/pci:00/:00:14.0/usb3/3-2/3-2.3/3-2.3:1.0/input/input15 Regards, -- Cristian Aravena Romero (caravena) -- 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: ASMedia SATA Bridge not enumerating without quirk
So this is a brown paper bag moment, I don't use usb-uas on my laptop,
so the kernel always does the right thing (I've enabled it now I know
about it)
The router has usb-uas compiled as a module, but didn't have it
installed, it's not one of the default ones it seems
After installing kmod-usb-storage-uas everything kicked into life
Sorry for the noise
On 21 March 2018 at 17:55, Mike Lothian wrote:
> Lastly here's the lsusb -v and dmesg from 4.9.87 on the router without
> the quirk added
>
> On 21 March 2018 at 17:50, Mike Lothian wrote:
>> Also here's the kernel config for the router, it's now 4.9.87
>>
>>
>>
>> On 21 March 2018 at 17:23, Menion wrote:
>>> Yes that was the point.
>>> Curious that the device worked fine in 17.01.4 and not in snapshot,
>>> but in 17.01.4 do you remember if it went in UAS or USB-STORAGE mode?
>>> I cannot answer here, but I am wondering if it is possible that if the
>>> kernel is compiled without UAS support, then a device showing UASP
>>> capability won't get enumerated at all instead of being downgraded to
>>> usb-storage.
>>>
>>> 2018-03-21 18:19 GMT+01:00 Mike Lothian :
Sorry I'm not sure what you mean by that, would you like the output of
lsusb -v before and after the quirk is added? And again from my
laptop?
I'd like to point the device worked fine when running a 4.4 kernel on
LEDE 17.01.4
On 21 March 2018 at 17:10, Menion wrote:
> Then it is so strange, it is completely dead from USB host perspective
> in UASP mode
> What lsusb shows when it is attached in UASP mode?
> Can you test it with some "regular" host with USB 3.0, like a PC?
>
> 2018-03-21 18:07 GMT+01:00 Mike Lothian :
>> Sorry, yes that was me disconnecting the device and reconnecting it,
>> just to confirm that it was the quirk that was fixing things (I might
>> not have connected it into the same port)
>>
>> I am changing the quirks in the modules config and reattaching,
>> modprobe on this device doesn't seem to let me specify options
>>
>> It's a USB3 caddy that has its own power supply, that you can put any
>> SATA hard disk into, I currently have a 1.5TB drive in it.
>>
>> On 21 March 2018 at 17:00, Menion wrote:
>>> I see a disconnect from port 4:1 of some un-enumerated device then
>>> connect to port 2:1 with UAS blacklist:
>>>
>>> [ 281.814757] usb 4-1: USB disconnect, device number 2
>>> [ 283.418292] usb 2-1: new SuperSpeed USB device number 2 using
>>> xhci-hcd
>>> [ 482.153319] usb 2-1: USB disconnect, device number 2
>>> [ 484.250856] usb 2-1: UAS is blacklisted for this device, using
>>> usb-storage instead
>>> [ 484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
>>> [ 484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa:
>>> c0
>>> [ 484.264432] scsi host1: usb-storage 2-1:1.0
>>>
>>> Are you peraphs changing the quirks in the modules config and reattach
>>> the device?
>>> Anyhow I see some strange reset from the USB host. What is this
>>> device? Perhaps some self-powered external HDD?
>>>
>>> 2018-03-21 17:56 GMT+01:00 Mike Lothian :
It had both, as did my follow up, the follow up should be more clear
though
On 21 March 2018 at 16:45, Menion wrote:
> You sent the dmesg with quirks :u enabled
> We need the one without quirks :u, when the device takes UAS driver
> Bye
>
> 2018-03-21 17:41 GMT+01:00 Mike Lothian :
>> Hi
>>
>> Please find attached my dmesg
>>
>> Cheers
>>
>> Mike
>>
>> On 21 March 2018 at 16:12, Oliver Neukum wrote:
>>> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
> I'm guessing it doesn't quite match up with the rules already in
> place
> in uas-detect.h
That device has a quirk already as a "normal" usb-storage device.
Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add
quirk
for mandatory READ_CAPACITY_16")
>>>
>>> That should cause different symptoms.
>>>
> Looks like it's an ASM1053 that can't do UAS
No, it's not a UAS device, is someone trying to recycle device ids
to do
different things now? That's not good :(
>>>
>>> The second interface looks like UAS though. The second interface
>>> looks
>>> like UAS though. What exactly does happen when you ennumerate?
>>> Dmesg please.
>>>
>>> We may need some exotic logic for these devices.
>>>
>>> Regards
>>> Oliver
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a
Re: ASMedia SATA Bridge not enumerating without quirk
Lastly here's the lsusb -v and dmesg from 4.9.87 on the router without
the quirk added
On 21 March 2018 at 17:50, Mike Lothian wrote:
> Also here's the kernel config for the router, it's now 4.9.87
>
>
>
> On 21 March 2018 at 17:23, Menion wrote:
>> Yes that was the point.
>> Curious that the device worked fine in 17.01.4 and not in snapshot,
>> but in 17.01.4 do you remember if it went in UAS or USB-STORAGE mode?
>> I cannot answer here, but I am wondering if it is possible that if the
>> kernel is compiled without UAS support, then a device showing UASP
>> capability won't get enumerated at all instead of being downgraded to
>> usb-storage.
>>
>> 2018-03-21 18:19 GMT+01:00 Mike Lothian :
>>> Sorry I'm not sure what you mean by that, would you like the output of
>>> lsusb -v before and after the quirk is added? And again from my
>>> laptop?
>>>
>>> I'd like to point the device worked fine when running a 4.4 kernel on
>>> LEDE 17.01.4
>>>
>>> On 21 March 2018 at 17:10, Menion wrote:
Then it is so strange, it is completely dead from USB host perspective
in UASP mode
What lsusb shows when it is attached in UASP mode?
Can you test it with some "regular" host with USB 3.0, like a PC?
2018-03-21 18:07 GMT+01:00 Mike Lothian :
> Sorry, yes that was me disconnecting the device and reconnecting it,
> just to confirm that it was the quirk that was fixing things (I might
> not have connected it into the same port)
>
> I am changing the quirks in the modules config and reattaching,
> modprobe on this device doesn't seem to let me specify options
>
> It's a USB3 caddy that has its own power supply, that you can put any
> SATA hard disk into, I currently have a 1.5TB drive in it.
>
> On 21 March 2018 at 17:00, Menion wrote:
>> I see a disconnect from port 4:1 of some un-enumerated device then
>> connect to port 2:1 with UAS blacklist:
>>
>> [ 281.814757] usb 4-1: USB disconnect, device number 2
>> [ 283.418292] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>> [ 482.153319] usb 2-1: USB disconnect, device number 2
>> [ 484.250856] usb 2-1: UAS is blacklisted for this device, using
>> usb-storage instead
>> [ 484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
>> [ 484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa:
>> c0
>> [ 484.264432] scsi host1: usb-storage 2-1:1.0
>>
>> Are you peraphs changing the quirks in the modules config and reattach
>> the device?
>> Anyhow I see some strange reset from the USB host. What is this
>> device? Perhaps some self-powered external HDD?
>>
>> 2018-03-21 17:56 GMT+01:00 Mike Lothian :
>>> It had both, as did my follow up, the follow up should be more clear
>>> though
>>>
>>> On 21 March 2018 at 16:45, Menion wrote:
You sent the dmesg with quirks :u enabled
We need the one without quirks :u, when the device takes UAS driver
Bye
2018-03-21 17:41 GMT+01:00 Mike Lothian :
> Hi
>
> Please find attached my dmesg
>
> Cheers
>
> Mike
>
> On 21 March 2018 at 16:12, Oliver Neukum wrote:
>> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>>> > I'm guessing it doesn't quite match up with the rules already in
>>> > place
>>> > in uas-detect.h
>>>
>>> That device has a quirk already as a "normal" usb-storage device.
>>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add
>>> quirk
>>> for mandatory READ_CAPACITY_16")
>>
>> That should cause different symptoms.
>>
>>> > Looks like it's an ASM1053 that can't do UAS
>>>
>>> No, it's not a UAS device, is someone trying to recycle device ids
>>> to do
>>> different things now? That's not good :(
>>
>> The second interface looks like UAS though. The second interface
>> looks
>> like UAS though. What exactly does happen when you ennumerate?
>> Dmesg please.
>>
>> We may need some exotic logic for these devices.
>>
>> Regards
>> Oliver
>>
dmesg
Description: Binary data
lsusb
Description: Binary data
Re: ASMedia SATA Bridge not enumerating without quirk
Also here's the kernel config for the router, it's now 4.9.87
On 21 March 2018 at 17:23, Menion wrote:
> Yes that was the point.
> Curious that the device worked fine in 17.01.4 and not in snapshot,
> but in 17.01.4 do you remember if it went in UAS or USB-STORAGE mode?
> I cannot answer here, but I am wondering if it is possible that if the
> kernel is compiled without UAS support, then a device showing UASP
> capability won't get enumerated at all instead of being downgraded to
> usb-storage.
>
> 2018-03-21 18:19 GMT+01:00 Mike Lothian :
>> Sorry I'm not sure what you mean by that, would you like the output of
>> lsusb -v before and after the quirk is added? And again from my
>> laptop?
>>
>> I'd like to point the device worked fine when running a 4.4 kernel on
>> LEDE 17.01.4
>>
>> On 21 March 2018 at 17:10, Menion wrote:
>>> Then it is so strange, it is completely dead from USB host perspective
>>> in UASP mode
>>> What lsusb shows when it is attached in UASP mode?
>>> Can you test it with some "regular" host with USB 3.0, like a PC?
>>>
>>> 2018-03-21 18:07 GMT+01:00 Mike Lothian :
Sorry, yes that was me disconnecting the device and reconnecting it,
just to confirm that it was the quirk that was fixing things (I might
not have connected it into the same port)
I am changing the quirks in the modules config and reattaching,
modprobe on this device doesn't seem to let me specify options
It's a USB3 caddy that has its own power supply, that you can put any
SATA hard disk into, I currently have a 1.5TB drive in it.
On 21 March 2018 at 17:00, Menion wrote:
> I see a disconnect from port 4:1 of some un-enumerated device then
> connect to port 2:1 with UAS blacklist:
>
> [ 281.814757] usb 4-1: USB disconnect, device number 2
> [ 283.418292] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
> [ 482.153319] usb 2-1: USB disconnect, device number 2
> [ 484.250856] usb 2-1: UAS is blacklisted for this device, using
> usb-storage instead
> [ 484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
> [ 484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa:
> c0
> [ 484.264432] scsi host1: usb-storage 2-1:1.0
>
> Are you peraphs changing the quirks in the modules config and reattach
> the device?
> Anyhow I see some strange reset from the USB host. What is this
> device? Perhaps some self-powered external HDD?
>
> 2018-03-21 17:56 GMT+01:00 Mike Lothian :
>> It had both, as did my follow up, the follow up should be more clear
>> though
>>
>> On 21 March 2018 at 16:45, Menion wrote:
>>> You sent the dmesg with quirks :u enabled
>>> We need the one without quirks :u, when the device takes UAS driver
>>> Bye
>>>
>>> 2018-03-21 17:41 GMT+01:00 Mike Lothian :
Hi
Please find attached my dmesg
Cheers
Mike
On 21 March 2018 at 16:12, Oliver Neukum wrote:
> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>> > I'm guessing it doesn't quite match up with the rules already in
>> > place
>> > in uas-detect.h
>>
>> That device has a quirk already as a "normal" usb-storage device.
>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add
>> quirk
>> for mandatory READ_CAPACITY_16")
>
> That should cause different symptoms.
>
>> > Looks like it's an ASM1053 that can't do UAS
>>
>> No, it's not a UAS device, is someone trying to recycle device ids
>> to do
>> different things now? That's not good :(
>
> The second interface looks like UAS though. The second interface looks
> like UAS though. What exactly does happen when you ennumerate?
> Dmesg please.
>
> We may need some exotic logic for these devices.
>
> Regards
> Oliver
>
config.gz
Description: application/gzip
Re: ASMedia SATA Bridge not enumerating without quirk
OK here's what's on my laptop, running 4.16-rc1, I didn't need to enter a quirk
On 21 March 2018 at 17:23, Menion wrote:
> Yes that was the point.
> Curious that the device worked fine in 17.01.4 and not in snapshot,
> but in 17.01.4 do you remember if it went in UAS or USB-STORAGE mode?
> I cannot answer here, but I am wondering if it is possible that if the
> kernel is compiled without UAS support, then a device showing UASP
> capability won't get enumerated at all instead of being downgraded to
> usb-storage.
>
> 2018-03-21 18:19 GMT+01:00 Mike Lothian :
>> Sorry I'm not sure what you mean by that, would you like the output of
>> lsusb -v before and after the quirk is added? And again from my
>> laptop?
>>
>> I'd like to point the device worked fine when running a 4.4 kernel on
>> LEDE 17.01.4
>>
>> On 21 March 2018 at 17:10, Menion wrote:
>>> Then it is so strange, it is completely dead from USB host perspective
>>> in UASP mode
>>> What lsusb shows when it is attached in UASP mode?
>>> Can you test it with some "regular" host with USB 3.0, like a PC?
>>>
>>> 2018-03-21 18:07 GMT+01:00 Mike Lothian :
Sorry, yes that was me disconnecting the device and reconnecting it,
just to confirm that it was the quirk that was fixing things (I might
not have connected it into the same port)
I am changing the quirks in the modules config and reattaching,
modprobe on this device doesn't seem to let me specify options
It's a USB3 caddy that has its own power supply, that you can put any
SATA hard disk into, I currently have a 1.5TB drive in it.
On 21 March 2018 at 17:00, Menion wrote:
> I see a disconnect from port 4:1 of some un-enumerated device then
> connect to port 2:1 with UAS blacklist:
>
> [ 281.814757] usb 4-1: USB disconnect, device number 2
> [ 283.418292] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
> [ 482.153319] usb 2-1: USB disconnect, device number 2
> [ 484.250856] usb 2-1: UAS is blacklisted for this device, using
> usb-storage instead
> [ 484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
> [ 484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa:
> c0
> [ 484.264432] scsi host1: usb-storage 2-1:1.0
>
> Are you peraphs changing the quirks in the modules config and reattach
> the device?
> Anyhow I see some strange reset from the USB host. What is this
> device? Perhaps some self-powered external HDD?
>
> 2018-03-21 17:56 GMT+01:00 Mike Lothian :
>> It had both, as did my follow up, the follow up should be more clear
>> though
>>
>> On 21 March 2018 at 16:45, Menion wrote:
>>> You sent the dmesg with quirks :u enabled
>>> We need the one without quirks :u, when the device takes UAS driver
>>> Bye
>>>
>>> 2018-03-21 17:41 GMT+01:00 Mike Lothian :
Hi
Please find attached my dmesg
Cheers
Mike
On 21 March 2018 at 16:12, Oliver Neukum wrote:
> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>> > I'm guessing it doesn't quite match up with the rules already in
>> > place
>> > in uas-detect.h
>>
>> That device has a quirk already as a "normal" usb-storage device.
>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add
>> quirk
>> for mandatory READ_CAPACITY_16")
>
> That should cause different symptoms.
>
>> > Looks like it's an ASM1053 that can't do UAS
>>
>> No, it's not a UAS device, is someone trying to recycle device ids
>> to do
>> different things now? That's not good :(
>
> The second interface looks like UAS though. The second interface looks
> like UAS though. What exactly does happen when you ennumerate?
> Dmesg please.
>
> We may need some exotic logic for these devices.
>
> Regards
> Oliver
>
dmesg.usb
Description: Binary data
lsusb
Description: Binary data
Re: linux-next: Tree for Mar 21 (usb/dwc3)
On 03/21/2018 01:25 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20180320: > on i386: ERROR: "__tracepoint_dwc3_gadget_generic_cmd" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_ep_queue" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_free_request" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_event" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_gadget_ep_enable" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_alloc_request" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_prepare_trb" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_complete_trb" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_writel" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_readl" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_gadget_ep_cmd" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_ctrl_req" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_ep_dequeue" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_gadget_giveback" [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: "__tracepoint_dwc3_gadget_ep_disable" [drivers/usb/dwc3/dwc3.ko] undefined! Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/i386 4.16.0-rc6 Kernel Configuration # CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_BITS_MAX=16 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=2 CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_KERNEL_LZ4=y CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SYSVIPC=y # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_USELIB=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_SIM=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y CONFIG_IRQ_TIME_ACCOUNTING=y # CONFIG_CPU_ISOLATION is not set # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_RCU_EXPERT=y CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_RCU_FAST_NO_HZ=y CONFIG_RCU_NOCB_CPU=y CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y # CONFIG_CGROUPS is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y # CONFIG_RD_LZMA is not set CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y # CONFIG_CC_OPTIMIZE_FOR
Re: ASMedia SATA Bridge not enumerating without quirk
Yes that was the point.
Curious that the device worked fine in 17.01.4 and not in snapshot,
but in 17.01.4 do you remember if it went in UAS or USB-STORAGE mode?
I cannot answer here, but I am wondering if it is possible that if the
kernel is compiled without UAS support, then a device showing UASP
capability won't get enumerated at all instead of being downgraded to
usb-storage.
2018-03-21 18:19 GMT+01:00 Mike Lothian :
> Sorry I'm not sure what you mean by that, would you like the output of
> lsusb -v before and after the quirk is added? And again from my
> laptop?
>
> I'd like to point the device worked fine when running a 4.4 kernel on
> LEDE 17.01.4
>
> On 21 March 2018 at 17:10, Menion wrote:
>> Then it is so strange, it is completely dead from USB host perspective
>> in UASP mode
>> What lsusb shows when it is attached in UASP mode?
>> Can you test it with some "regular" host with USB 3.0, like a PC?
>>
>> 2018-03-21 18:07 GMT+01:00 Mike Lothian :
>>> Sorry, yes that was me disconnecting the device and reconnecting it,
>>> just to confirm that it was the quirk that was fixing things (I might
>>> not have connected it into the same port)
>>>
>>> I am changing the quirks in the modules config and reattaching,
>>> modprobe on this device doesn't seem to let me specify options
>>>
>>> It's a USB3 caddy that has its own power supply, that you can put any
>>> SATA hard disk into, I currently have a 1.5TB drive in it.
>>>
>>> On 21 March 2018 at 17:00, Menion wrote:
I see a disconnect from port 4:1 of some un-enumerated device then
connect to port 2:1 with UAS blacklist:
[ 281.814757] usb 4-1: USB disconnect, device number 2
[ 283.418292] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
[ 482.153319] usb 2-1: USB disconnect, device number 2
[ 484.250856] usb 2-1: UAS is blacklisted for this device, using
usb-storage instead
[ 484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa:
c0
[ 484.264432] scsi host1: usb-storage 2-1:1.0
Are you peraphs changing the quirks in the modules config and reattach
the device?
Anyhow I see some strange reset from the USB host. What is this
device? Perhaps some self-powered external HDD?
2018-03-21 17:56 GMT+01:00 Mike Lothian :
> It had both, as did my follow up, the follow up should be more clear
> though
>
> On 21 March 2018 at 16:45, Menion wrote:
>> You sent the dmesg with quirks :u enabled
>> We need the one without quirks :u, when the device takes UAS driver
>> Bye
>>
>> 2018-03-21 17:41 GMT+01:00 Mike Lothian :
>>> Hi
>>>
>>> Please find attached my dmesg
>>>
>>> Cheers
>>>
>>> Mike
>>>
>>> On 21 March 2018 at 16:12, Oliver Neukum wrote:
Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
> > I'm guessing it doesn't quite match up with the rules already in
> > place
> > in uas-detect.h
>
> That device has a quirk already as a "normal" usb-storage device.
> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add
> quirk
> for mandatory READ_CAPACITY_16")
That should cause different symptoms.
> > Looks like it's an ASM1053 that can't do UAS
>
> No, it's not a UAS device, is someone trying to recycle device ids to
> do
> different things now? That's not good :(
The second interface looks like UAS though. The second interface looks
like UAS though. What exactly does happen when you ennumerate?
Dmesg please.
We may need some exotic logic for these devices.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASMedia SATA Bridge not enumerating without quirk
Sorry I'm not sure what you mean by that, would you like the output of
lsusb -v before and after the quirk is added? And again from my
laptop?
I'd like to point the device worked fine when running a 4.4 kernel on
LEDE 17.01.4
On 21 March 2018 at 17:10, Menion wrote:
> Then it is so strange, it is completely dead from USB host perspective
> in UASP mode
> What lsusb shows when it is attached in UASP mode?
> Can you test it with some "regular" host with USB 3.0, like a PC?
>
> 2018-03-21 18:07 GMT+01:00 Mike Lothian :
>> Sorry, yes that was me disconnecting the device and reconnecting it,
>> just to confirm that it was the quirk that was fixing things (I might
>> not have connected it into the same port)
>>
>> I am changing the quirks in the modules config and reattaching,
>> modprobe on this device doesn't seem to let me specify options
>>
>> It's a USB3 caddy that has its own power supply, that you can put any
>> SATA hard disk into, I currently have a 1.5TB drive in it.
>>
>> On 21 March 2018 at 17:00, Menion wrote:
>>> I see a disconnect from port 4:1 of some un-enumerated device then
>>> connect to port 2:1 with UAS blacklist:
>>>
>>> [ 281.814757] usb 4-1: USB disconnect, device number 2
>>> [ 283.418292] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>>> [ 482.153319] usb 2-1: USB disconnect, device number 2
>>> [ 484.250856] usb 2-1: UAS is blacklisted for this device, using
>>> usb-storage instead
>>> [ 484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
>>> [ 484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa:
>>> c0
>>> [ 484.264432] scsi host1: usb-storage 2-1:1.0
>>>
>>> Are you peraphs changing the quirks in the modules config and reattach
>>> the device?
>>> Anyhow I see some strange reset from the USB host. What is this
>>> device? Perhaps some self-powered external HDD?
>>>
>>> 2018-03-21 17:56 GMT+01:00 Mike Lothian :
It had both, as did my follow up, the follow up should be more clear though
On 21 March 2018 at 16:45, Menion wrote:
> You sent the dmesg with quirks :u enabled
> We need the one without quirks :u, when the device takes UAS driver
> Bye
>
> 2018-03-21 17:41 GMT+01:00 Mike Lothian :
>> Hi
>>
>> Please find attached my dmesg
>>
>> Cheers
>>
>> Mike
>>
>> On 21 March 2018 at 16:12, Oliver Neukum wrote:
>>> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
> I'm guessing it doesn't quite match up with the rules already in
> place
> in uas-detect.h
That device has a quirk already as a "normal" usb-storage device.
Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
for mandatory READ_CAPACITY_16")
>>>
>>> That should cause different symptoms.
>>>
> Looks like it's an ASM1053 that can't do UAS
No, it's not a UAS device, is someone trying to recycle device ids to
do
different things now? That's not good :(
>>>
>>> The second interface looks like UAS though. The second interface looks
>>> like UAS though. What exactly does happen when you ennumerate?
>>> Dmesg please.
>>>
>>> We may need some exotic logic for these devices.
>>>
>>> Regards
>>> Oliver
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASMedia SATA Bridge not enumerating without quirk
Then it is so strange, it is completely dead from USB host perspective
in UASP mode
What lsusb shows when it is attached in UASP mode?
Can you test it with some "regular" host with USB 3.0, like a PC?
2018-03-21 18:07 GMT+01:00 Mike Lothian :
> Sorry, yes that was me disconnecting the device and reconnecting it,
> just to confirm that it was the quirk that was fixing things (I might
> not have connected it into the same port)
>
> I am changing the quirks in the modules config and reattaching,
> modprobe on this device doesn't seem to let me specify options
>
> It's a USB3 caddy that has its own power supply, that you can put any
> SATA hard disk into, I currently have a 1.5TB drive in it.
>
> On 21 March 2018 at 17:00, Menion wrote:
>> I see a disconnect from port 4:1 of some un-enumerated device then
>> connect to port 2:1 with UAS blacklist:
>>
>> [ 281.814757] usb 4-1: USB disconnect, device number 2
>> [ 283.418292] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>> [ 482.153319] usb 2-1: USB disconnect, device number 2
>> [ 484.250856] usb 2-1: UAS is blacklisted for this device, using
>> usb-storage instead
>> [ 484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
>> [ 484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa:
>> c0
>> [ 484.264432] scsi host1: usb-storage 2-1:1.0
>>
>> Are you peraphs changing the quirks in the modules config and reattach
>> the device?
>> Anyhow I see some strange reset from the USB host. What is this
>> device? Perhaps some self-powered external HDD?
>>
>> 2018-03-21 17:56 GMT+01:00 Mike Lothian :
>>> It had both, as did my follow up, the follow up should be more clear though
>>>
>>> On 21 March 2018 at 16:45, Menion wrote:
You sent the dmesg with quirks :u enabled
We need the one without quirks :u, when the device takes UAS driver
Bye
2018-03-21 17:41 GMT+01:00 Mike Lothian :
> Hi
>
> Please find attached my dmesg
>
> Cheers
>
> Mike
>
> On 21 March 2018 at 16:12, Oliver Neukum wrote:
>> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>>> > I'm guessing it doesn't quite match up with the rules already in place
>>> > in uas-detect.h
>>>
>>> That device has a quirk already as a "normal" usb-storage device.
>>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
>>> for mandatory READ_CAPACITY_16")
>>
>> That should cause different symptoms.
>>
>>> > Looks like it's an ASM1053 that can't do UAS
>>>
>>> No, it's not a UAS device, is someone trying to recycle device ids to do
>>> different things now? That's not good :(
>>
>> The second interface looks like UAS though. The second interface looks
>> like UAS though. What exactly does happen when you ennumerate?
>> Dmesg please.
>>
>> We may need some exotic logic for these devices.
>>
>> Regards
>> Oliver
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASMedia SATA Bridge not enumerating without quirk
Sorry, yes that was me disconnecting the device and reconnecting it,
just to confirm that it was the quirk that was fixing things (I might
not have connected it into the same port)
I am changing the quirks in the modules config and reattaching,
modprobe on this device doesn't seem to let me specify options
It's a USB3 caddy that has its own power supply, that you can put any
SATA hard disk into, I currently have a 1.5TB drive in it.
On 21 March 2018 at 17:00, Menion wrote:
> I see a disconnect from port 4:1 of some un-enumerated device then
> connect to port 2:1 with UAS blacklist:
>
> [ 281.814757] usb 4-1: USB disconnect, device number 2
> [ 283.418292] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
> [ 482.153319] usb 2-1: USB disconnect, device number 2
> [ 484.250856] usb 2-1: UAS is blacklisted for this device, using
> usb-storage instead
> [ 484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
> [ 484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c0
> [ 484.264432] scsi host1: usb-storage 2-1:1.0
>
> Are you peraphs changing the quirks in the modules config and reattach
> the device?
> Anyhow I see some strange reset from the USB host. What is this
> device? Perhaps some self-powered external HDD?
>
> 2018-03-21 17:56 GMT+01:00 Mike Lothian :
>> It had both, as did my follow up, the follow up should be more clear though
>>
>> On 21 March 2018 at 16:45, Menion wrote:
>>> You sent the dmesg with quirks :u enabled
>>> We need the one without quirks :u, when the device takes UAS driver
>>> Bye
>>>
>>> 2018-03-21 17:41 GMT+01:00 Mike Lothian :
Hi
Please find attached my dmesg
Cheers
Mike
On 21 March 2018 at 16:12, Oliver Neukum wrote:
> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>> > I'm guessing it doesn't quite match up with the rules already in place
>> > in uas-detect.h
>>
>> That device has a quirk already as a "normal" usb-storage device.
>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
>> for mandatory READ_CAPACITY_16")
>
> That should cause different symptoms.
>
>> > Looks like it's an ASM1053 that can't do UAS
>>
>> No, it's not a UAS device, is someone trying to recycle device ids to do
>> different things now? That's not good :(
>
> The second interface looks like UAS though. The second interface looks
> like UAS though. What exactly does happen when you ennumerate?
> Dmesg please.
>
> We may need some exotic logic for these devices.
>
> Regards
> Oliver
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASMedia SATA Bridge not enumerating without quirk
I see a disconnect from port 4:1 of some un-enumerated device then
connect to port 2:1 with UAS blacklist:
[ 281.814757] usb 4-1: USB disconnect, device number 2
[ 283.418292] usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
[ 482.153319] usb 2-1: USB disconnect, device number 2
[ 484.250856] usb 2-1: UAS is blacklisted for this device, using
usb-storage instead
[ 484.250901] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 484.258055] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c0
[ 484.264432] scsi host1: usb-storage 2-1:1.0
Are you peraphs changing the quirks in the modules config and reattach
the device?
Anyhow I see some strange reset from the USB host. What is this
device? Perhaps some self-powered external HDD?
2018-03-21 17:56 GMT+01:00 Mike Lothian :
> It had both, as did my follow up, the follow up should be more clear though
>
> On 21 March 2018 at 16:45, Menion wrote:
>> You sent the dmesg with quirks :u enabled
>> We need the one without quirks :u, when the device takes UAS driver
>> Bye
>>
>> 2018-03-21 17:41 GMT+01:00 Mike Lothian :
>>> Hi
>>>
>>> Please find attached my dmesg
>>>
>>> Cheers
>>>
>>> Mike
>>>
>>> On 21 March 2018 at 16:12, Oliver Neukum wrote:
Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
> > I'm guessing it doesn't quite match up with the rules already in place
> > in uas-detect.h
>
> That device has a quirk already as a "normal" usb-storage device.
> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
> for mandatory READ_CAPACITY_16")
That should cause different symptoms.
> > Looks like it's an ASM1053 that can't do UAS
>
> No, it's not a UAS device, is someone trying to recycle device ids to do
> different things now? That's not good :(
The second interface looks like UAS though. The second interface looks
like UAS though. What exactly does happen when you ennumerate?
Dmesg please.
We may need some exotic logic for these devices.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASMedia SATA Bridge not enumerating without quirk
It had both, as did my follow up, the follow up should be more clear though
On 21 March 2018 at 16:45, Menion wrote:
> You sent the dmesg with quirks :u enabled
> We need the one without quirks :u, when the device takes UAS driver
> Bye
>
> 2018-03-21 17:41 GMT+01:00 Mike Lothian :
>> Hi
>>
>> Please find attached my dmesg
>>
>> Cheers
>>
>> Mike
>>
>> On 21 March 2018 at 16:12, Oliver Neukum wrote:
>>> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
> I'm guessing it doesn't quite match up with the rules already in place
> in uas-detect.h
That device has a quirk already as a "normal" usb-storage device.
Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
for mandatory READ_CAPACITY_16")
>>>
>>> That should cause different symptoms.
>>>
> Looks like it's an ASM1053 that can't do UAS
No, it's not a UAS device, is someone trying to recycle device ids to do
different things now? That's not good :(
>>>
>>> The second interface looks like UAS though. The second interface looks
>>> like UAS though. What exactly does happen when you ennumerate?
>>> Dmesg please.
>>>
>>> We may need some exotic logic for these devices.
>>>
>>> Regards
>>> Oliver
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASMedia SATA Bridge not enumerating without quirk
So I rebooted my router, and repeated without the other usb stick attached
So you should have it with it booting without the quirk, reconnecting
without the quirk, then reconnecting with the quirk, where the hard
disk is enumerated
On 21 March 2018 at 16:41, Mike Lothian wrote:
> Hi
>
> Please find attached my dmesg
>
> Cheers
>
> Mike
>
> On 21 March 2018 at 16:12, Oliver Neukum wrote:
>> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>>> > I'm guessing it doesn't quite match up with the rules already in place
>>> > in uas-detect.h
>>>
>>> That device has a quirk already as a "normal" usb-storage device.
>>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
>>> for mandatory READ_CAPACITY_16")
>>
>> That should cause different symptoms.
>>
>>> > Looks like it's an ASM1053 that can't do UAS
>>>
>>> No, it's not a UAS device, is someone trying to recycle device ids to do
>>> different things now? That's not good :(
>>
>> The second interface looks like UAS though. The second interface looks
>> like UAS though. What exactly does happen when you ennumerate?
>> Dmesg please.
>>
>> We may need some exotic logic for these devices.
>>
>> Regards
>> Oliver
>>
dmesg
Description: Binary data
Re: ASMedia SATA Bridge not enumerating without quirk
You sent the dmesg with quirks :u enabled
We need the one without quirks :u, when the device takes UAS driver
Bye
2018-03-21 17:41 GMT+01:00 Mike Lothian :
> Hi
>
> Please find attached my dmesg
>
> Cheers
>
> Mike
>
> On 21 March 2018 at 16:12, Oliver Neukum wrote:
>> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>>> > I'm guessing it doesn't quite match up with the rules already in place
>>> > in uas-detect.h
>>>
>>> That device has a quirk already as a "normal" usb-storage device.
>>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
>>> for mandatory READ_CAPACITY_16")
>>
>> That should cause different symptoms.
>>
>>> > Looks like it's an ASM1053 that can't do UAS
>>>
>>> No, it's not a UAS device, is someone trying to recycle device ids to do
>>> different things now? That's not good :(
>>
>> The second interface looks like UAS though. The second interface looks
>> like UAS though. What exactly does happen when you ennumerate?
>> Dmesg please.
>>
>> We may need some exotic logic for these devices.
>>
>> Regards
>> Oliver
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASMedia SATA Bridge not enumerating without quirk
Hi
Please find attached my dmesg
Cheers
Mike
On 21 March 2018 at 16:12, Oliver Neukum wrote:
> Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
>> > I'm guessing it doesn't quite match up with the rules already in place
>> > in uas-detect.h
>>
>> That device has a quirk already as a "normal" usb-storage device.
>> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
>> for mandatory READ_CAPACITY_16")
>
> That should cause different symptoms.
>
>> > Looks like it's an ASM1053 that can't do UAS
>>
>> No, it's not a UAS device, is someone trying to recycle device ids to do
>> different things now? That's not good :(
>
> The second interface looks like UAS though. The second interface looks
> like UAS though. What exactly does happen when you ennumerate?
> Dmesg please.
>
> We may need some exotic logic for these devices.
>
> Regards
> Oliver
>
dmesg
Description: Binary data
Re: ASMedia SATA Bridge not enumerating without quirk
Am Mittwoch, den 21.03.2018, 17:09 +0100 schrieb Greg KH:
> > I'm guessing it doesn't quite match up with the rules already in place
> > in uas-detect.h
>
> That device has a quirk already as a "normal" usb-storage device.
> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
> for mandatory READ_CAPACITY_16")
That should cause different symptoms.
> > Looks like it's an ASM1053 that can't do UAS
>
> No, it's not a UAS device, is someone trying to recycle device ids to do
> different things now? That's not good :(
The second interface looks like UAS though. The second interface looks
like UAS though. What exactly does happen when you ennumerate?
Dmesg please.
We may need some exotic logic for these devices.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASMedia SATA Bridge not enumerating without quirk
READ_CAPACITY_16 does not have anything to do in blacklisting via
quirks the device to usb-storage
I have checked it in 4.9.86 and it is not quirked to usb-storage:
/* Reported by Oliver Neukum */
UNUSUAL_DEV( 0x174c, 0x55aa, 0x0100, 0x0100,
"ASMedia",
"AS2105",
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_NEEDS_CAP16),
2018-03-21 17:09 GMT+01:00 Greg KH :
> On Wed, Mar 21, 2018 at 03:39:06PM +, Mike Lothian wrote:
>> Hi
>>
>> I'm running kernel 4.9.86 on my router
>>
>> I have to:
>>
>> echo 174c:55aa:u > /sys/module/usb_storage/parameters/quirks
>>
>> To get it to work correctly
>>
>> I'm attaching the output of lsusb -v
>>
>> I'm guessing it doesn't quite match up with the rules already in place
>> in uas-detect.h
>
> That device has a quirk already as a "normal" usb-storage device.
> Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
> for mandatory READ_CAPACITY_16")
>
>> Looks like it's an ASM1053 that can't do UAS
>
> No, it's not a UAS device, is someone trying to recycle device ids to do
> different things now? That's not 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
--
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: ASMedia SATA Bridge not enumerating without quirk
On Wed, Mar 21, 2018 at 03:39:06PM +, Mike Lothian wrote:
> Hi
>
> I'm running kernel 4.9.86 on my router
>
> I have to:
>
> echo 174c:55aa:u > /sys/module/usb_storage/parameters/quirks
>
> To get it to work correctly
>
> I'm attaching the output of lsusb -v
>
> I'm guessing it doesn't quite match up with the rules already in place
> in uas-detect.h
That device has a quirk already as a "normal" usb-storage device.
Oliver added it back in 2013 with 32c37fc30c52 ("usb-storage: add quirk
for mandatory READ_CAPACITY_16")
> Looks like it's an ASM1053 that can't do UAS
No, it's not a UAS device, is someone trying to recycle device ids to do
different things now? That's not 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: ASMedia SATA Bridge not enumerating without quirk
Can you please attach dmesg output? 2018-03-21 16:39 GMT+01:00 Mike Lothian : > Hi > > I'm running kernel 4.9.86 on my router > > I have to: > > echo 174c:55aa:u > /sys/module/usb_storage/parameters/quirks > > To get it to work correctly > > I'm attaching the output of lsusb -v > > I'm guessing it doesn't quite match up with the rules already in place > in uas-detect.h > > Looks like it's an ASM1053 that can't do UAS > > Regards > > Mike -- 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
ASMedia SATA Bridge not enumerating without quirk
Hi I'm running kernel 4.9.86 on my router I have to: echo 174c:55aa:u > /sys/module/usb_storage/parameters/quirks To get it to work correctly I'm attaching the output of lsusb -v I'm guessing it doesn't quite match up with the rules already in place in uas-detect.h Looks like it's an ASM1053 that can't do UAS Regards Mike lsusb Description: Binary data
Re: About patchwork for linux-usb
On Mon, Mar 19, 2018 at 08:57:07AM +, Peter Chen wrote: > > > > > > At some situations, we may need to save reviewing patches from web, > > > but I can't find linux-usb at > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.k > > ernel.org%2F&data=02%7C01%7Cpeter.chen%40nxp.com%7Cbef6ada7885641ed5 > > bf408d58b131139%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6365 > > 67836369109099&sdata=w8dVZjbsb%2BrboggllBzJbdkxR6r7BQHOEtf7tQ5mCPE% > > 3D&reserved=0, any there any patchworks for linux-usb mailist at Internet? > > Thanks. > > > > I do not know of any, as I do not use patchwork, sorry. If you feel that > > we should add > > it to patchwork.kernel.org, that can easily be done. > > > > thanks, > > > > Some may would like to test the reviewing patches, but they do not have the > tool like > mutt to save patches, it is useful for them. It will be great we would do > that, thanks. I've asked for it to be included. But really, you should use a good email client :) 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
[PATCH] HID: usbhid: extend the polling interval configuration to keyboards
For mouse and joystick devices user can change the polling interval
via usbhid.mousepoll and usbhid.jspoll.
Implement the same thing for keyboards, so user can
reduce(or increase) input latency this way.
This has been tested with a Cooler Master Devastator with
kbpoll=32, resulting in delay between events of 32 ms(values were taken
from evtest).
Signed-off-by: Filip Alac
---
Documentation/admin-guide/kernel-parameters.txt | 3 +++
drivers/hid/usbhid/hid-core.c | 12 +++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index b98048b56..e0d825206 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4352,6 +4352,9 @@
usbhid.jspoll=
[USBHID] The interval which joysticks are to be polled
at.
+ usbhid.kbpoll=
+ [USBHID] The interval which keyboards are to be polled
at.
+
usb-storage.delay_use=
[UMS] The delay in seconds before a new device is
scanned for Logical Units (default 1).
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 77c50cdff..af0e0d061 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -56,6 +56,10 @@ static unsigned int hid_jspoll_interval;
module_param_named(jspoll, hid_jspoll_interval, uint, 0644);
MODULE_PARM_DESC(jspoll, "Polling interval of joysticks");
+static unsigned int hid_kbpoll_interval;
+module_param_named(kbpoll, hid_kbpoll_interval, uint, 0644);
+MODULE_PARM_DESC(kbpoll, "Polling interval of keyboards");
+
static unsigned int ignoreled;
module_param_named(ignoreled, ignoreled, uint, 0644);
MODULE_PARM_DESC(ignoreled, "Autosuspend with active leds");
@@ -1094,7 +1098,9 @@ static int usbhid_start(struct hid_device *hid)
hid->name, endpoint->bInterval, interval);
}
- /* Change the polling interval of mice and joysticks. */
+ /* Change the polling interval of mice, joysticks
+* and keyboards.
+*/
switch (hid->collection->usage) {
case HID_GD_MOUSE:
if (hid_mousepoll_interval > 0)
@@ -1104,6 +1110,10 @@ static int usbhid_start(struct hid_device *hid)
if (hid_jspoll_interval > 0)
interval = hid_jspoll_interval;
break;
+ case HID_GD_KEYBOARD:
+ if (hid_kbpoll_interval > 0)
+ interval = hid_kbpoll_interval;
+ break;
}
ret = -ENOMEM;
--
2.16.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 v5 2/2] usb/gadget/uvc-configfs Fix linked flag in a format not being set when format is linked into streaming header
While checks are in place to avoid attributes and children of a format being manipulated after the format is linked into the streaming header, the linked flag was never actually set, invalidating the protections. Signed-off-by: Joel Pepper --- drivers/usb/gadget/function/uvc_configfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/gadget/function/uvc_configfs.c b/drivers/usb/gadget/function/uvc_configfs.c index ab64925..37b4a14 100644 --- a/drivers/usb/gadget/function/uvc_configfs.c +++ b/drivers/usb/gadget/function/uvc_configfs.c @@ -763,6 +763,7 @@ static int uvcg_streaming_header_allow_link(struct config_item *src, format_ptr->fmt = target_fmt; list_add_tail(&format_ptr->entry, &src_hdr->formats); ++src_hdr->num_fmt; + ++target_fmt->linked; out: mutex_unlock(&opts->lock); @@ -800,6 +801,8 @@ static void uvcg_streaming_header_drop_link(struct config_item *src, break; } + --target_fmt->linked; + out: mutex_unlock(&opts->lock); mutex_unlock(su_mutex); -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/2] usb/gadget/uvc-configfs usb/gadget/uvc-configs Fix host unable to negotiate framesizes other than first
This patchset is mostly concerned with fixing the driver setting incorrect bFrameIndexes which breaks frame descriptor negotiation, for details refer to the first patch. However this fix needed another bug relating to the "linked" flag not being set on formats to be fixed first. As this bug has farther reaching implications, I have included the relevant fix as an independent patch Joel Pepper (2): usb/gadget/uvc-configs Fix host unable to negotiate framesizes other than first usb/gadget/uvc-configfs Fix linked flag in a format not being set when format is linked into streaming header Documentation/ABI/testing/configfs-usb-gadget-uvc | 18 ++ drivers/usb/gadget/function/uvc_configfs.c| 67 +++ 2 files changed, 85 insertions(+) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/2] usb/gadget/uvc-configs Fix host unable to negotiate framesizes other than first
- Add bFrameIndex as a UVCG_FRAME_ATTR_RO for each frame size.
- Automatically assign ascending bFrameIndex to each frame in a format.
Before all "bFrameindex" attributes were set to "1" with no way to
configure the gadget otherwise. This resulted in the host always
negotiating for bFrameIndex 1 (i.e. the first framesize of the gadget).
After the negotiation the host driver will set the user or application
selected framesize, while the gadget is actually set to the first
framesize.
Now, when the containing format is linked into the streaming header,
iterate over all child frame descriptors and assign ascending indices.
The automatically assigned indices can be read from the new read only
bFrameIndex configsfs attribute in each frame descriptor item.
v2: Add the new attribute to both MJPEG and uncompressed frame descriptors
in Documentation/ABI, with note that it was added only in a later
kernel version
v3: Changed from simply allowing user to set the value for bFrameIndex to
automatically assigning correct distinct frame indexes. Changed
bFrameIndex from RW to RO
v4: Actually include updated patch
v5: bFrameIndex now returns -EBUSY if the parent fmt is not linked yet
Signed-off-by: Joel Pepper
---
Documentation/ABI/testing/configfs-usb-gadget-uvc | 18 +++
drivers/usb/gadget/function/uvc_configfs.c| 64 +++
2 files changed, 82 insertions(+)
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc
b/Documentation/ABI/testing/configfs-usb-gadget-uvc
index 1ba0d0f..7bfec94 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
@@ -194,6 +194,14 @@ Description: Specific MJPEG frame descriptors
bmCapabilities - still image support, fixed frame-rate
support
+Date: Mar 2018
+KernelVersion: 4.16
+
+ bFrameIndex - unique id for this framedescriptor;
+ only defined after parent format is
+ linked into the streaming header;
+ read-only
+
What:
/config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed
Date: Dec 2014
KernelVersion: 4.0
@@ -241,6 +249,16 @@ Description: Specific uncompressed frame descriptors
bmCapabilities - still image support, fixed frame-rate
support
+Date: Mar 2018
+KernelVersion: 4.16
+
+bFrameIndex - unique id for this framedescriptor;
+only defined after parent format is
+linked into the streaming header;
+read-only
+
+
+
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/header
Date: Dec 2014
KernelVersion: 4.0
diff --git a/drivers/usb/gadget/function/uvc_configfs.c
b/drivers/usb/gadget/function/uvc_configfs.c
index c9b8cc4a..ab64925 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -32,6 +32,7 @@ static struct configfs_attribute prefix##attr_##cname = { \
}
static inline struct f_uvc_opts *to_f_uvc_opts(struct config_item *item);
+static void __uvcg_fmt_set_indices(struct config_group *fmt);
/* control/header/ */
DECLARE_UVC_HEADER_DESCRIPTOR(1);
@@ -751,6 +752,8 @@ static int uvcg_streaming_header_allow_link(struct
config_item *src,
if (!target_fmt)
goto out;
+ __uvcg_fmt_set_indices(to_config_group(target));
+
format_ptr = kzalloc(sizeof(*format_ptr), GFP_KERNEL);
if (!format_ptr) {
ret = -ENOMEM;
@@ -988,8 +991,46 @@ end:
\
\
UVC_ATTR(uvcg_frame_, cname, aname);
+
+static ssize_t uvcg_frame_b_frame_index_show(struct config_item *item,
+ char *page)
+{
+ struct uvcg_frame *f = to_uvcg_frame(item);
+ struct uvcg_format *fmt;
+ struct f_uvc_opts *opts;
+ struct config_item *opts_item;
+ struct config_item *fmt_item;
+ struct mutex *su_mutex = &f->item.ci_group->cg_subsys->su_mutex;
+ int result;
+
+ mutex_lock(su_mutex); /* for navigating configfs hierarchy */
+
+ fmt_item = f->item.ci_parent;
+ fmt = to_uvcg_format(fmt_item);
+
+ if (!fmt->linked) {
+ result = -EBUSY;
+ goto out;
+ }
+
+ opts_item = fmt_item->ci_parent->ci_parent->ci_parent;
+ opts = to_f_uvc_opts(opts_item);
+
+ mutex_lock(&opts->lock);
+ result = sprintf(page, "%d\n", f->frame.b_frame_index);
+ mutex_unlock(&opts->lock);
+
+out:
+ mutex_unlock(su_mutex);
+ return result;
+}
+
+UVC
Re: [PATCH v4] usb/gadget/uvc-configs Fix host unable to negotiate framesizes other than first
Please disregard this version, I discovered a different bug which needs
to be fixed before the -EBUSY behaviour can implemented, both will come
in v5
On 21.03.2018 11:20, Joel Pepper wrote:
> - Add bFrameIndex as a UVCG_FRAME_ATTR_RO for each frame size.
> - Automatically assign ascending bFrameIndex to each frame in a format.
>
> Before all "bFrameindex" attributes were set to "1" with no way to
> configure the gadget otherwise. This resulted in the host always
> negotiating for bFrameIndex 1 (i.e. the first framesize of the gadget).
> After the negotiation the host driver will set the user or application
> selected framesize, while the gadget is actually set to the first
> framesize.
>
> Now, when the containing format is linked into the streaming header,
> iterate over all child frame descriptors and assign ascending indices.
> The automatically assigned indices can be read from the new read only
> bFrameIndex configsfs attribute in each frame descriptor item.
>
> v2: Add the new attribute to both MJPEG and uncompressed frame descriptors
> in Documentation/ABI, with note that it was added only in a later
> kernel version
>
> v3: Changed from simply allowing user to set the value for bFrameIndex to
> automatically assigning correct distinct frame indexes. Changed
> bFrameIndex from RW to RO
>
> v4: Actually include updated patch
>
> Signed-off-by: Joel Pepper
> ---
> Documentation/ABI/testing/configfs-usb-gadget-uvc | 18
> drivers/usb/gadget/function/uvc_configfs.c| 53
> +++
> 2 files changed, 71 insertions(+)
>
> diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc
> b/Documentation/ABI/testing/configfs-usb-gadget-uvc
> index 1ba0d0f..872ed8a 100644
> --- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
> +++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
> @@ -194,6 +194,14 @@ Description: Specific MJPEG frame descriptors
> bmCapabilities - still image support, fixed frame-rate
> support
>
> +Date:Mar 2018
> +KernelVersion: 4.16
> +
> + bFrameIndex - unique id for this framedescriptor;
> + only defined after parent format is
> + linked into the streaming header;
> + read-only
> +
> What:
> /config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed
> Date:Dec 2014
> KernelVersion: 4.0
> @@ -241,6 +249,16 @@ Description: Specific uncompressed frame descriptors
> bmCapabilities - still image support, fixed frame-rate
> support
>
> +Date: Mar 2018
> +KernelVersion: 4.16
> +
> +bFrameIndex - unique id for this framedescriptor;
> +only defined after parent format is
> +linked into the streaming header;
> +read-only
> +
> +
> +
> What:
> /config/usb-gadget/gadget/functions/uvc.name/streaming/header
> Date:Dec 2014
> KernelVersion: 4.0
> diff --git a/drivers/usb/gadget/function/uvc_configfs.c
> b/drivers/usb/gadget/function/uvc_configfs.c
> index c9b8cc4a..a73dbc5 100644
> --- a/drivers/usb/gadget/function/uvc_configfs.c
> +++ b/drivers/usb/gadget/function/uvc_configfs.c
> @@ -32,6 +32,7 @@ static struct configfs_attribute prefix##attr_##cname = { \
> }
>
> static inline struct f_uvc_opts *to_f_uvc_opts(struct config_item *item);
> +static void __uvcg_fmt_set_indices(struct config_group* fmt);
>
> /* control/header/ */
> DECLARE_UVC_HEADER_DESCRIPTOR(1);
> @@ -751,6 +752,8 @@ static int uvcg_streaming_header_allow_link(struct
> config_item *src,
> if (!target_fmt)
> goto out;
>
> + __uvcg_fmt_set_indices(to_config_group(target));
> +
> format_ptr = kzalloc(sizeof(*format_ptr), GFP_KERNEL);
> if (!format_ptr) {
> ret = -ENOMEM;
> @@ -929,6 +932,30 @@ static struct uvcg_frame *to_uvcg_frame(struct
> config_item *item)
> return container_of(item, struct uvcg_frame, item);
> }
>
> +#define UVCG_FRAME_ATTR_RO(cname, aname, to_cpu_endian, to_little_endian,
> bits) \
> +static ssize_t uvcg_frame_##cname##_show(struct config_item *item, char
> *page)\
> +{\
> + struct uvcg_frame *f = to_uvcg_frame(item); \
> + struct f_uvc_opts *opts;\
> + struct config_item *opts_item; \
> + struct mutex *su_mutex = &f->item.ci_group->cg_subsys->su_mutex;\
> + int result; \
> +
Re: [usb-next PATCH] usb: xhci: skip phys initialization of shared hcd
On 21/03/18 13:50, Chunfeng Yun wrote:
> Hi Roger,
>
> On Wed, 2018-03-21 at 11:05 +0200, Roger Quadros wrote:
>> Hi Chunfeng,
>>
>> On 21/03/18 08:12, Chunfeng Yun wrote:
>>> The phys has already been initialized when add primary hcd,
>>> including usb2 phys and usb3 phys also if exist, so needn't
>>> re-parse "phys" property again.
>>>
>>> Signed-off-by: Chunfeng Yun
>>> ---
>>> drivers/usb/host/xhci-mtk.c | 1 +
>>> drivers/usb/host/xhci-plat.c | 1 +
>>> 2 files changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
>>> index 7334da9..6bb23fb 100644
>>> --- a/drivers/usb/host/xhci-mtk.c
>>> +++ b/drivers/usb/host/xhci-mtk.c
>>> @@ -554,6 +554,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
>>> if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
>>> xhci->shared_hcd->can_do_streams = 1;
>>>
>>> + xhci->shared_hcd->skip_phy_initialization = 1;
>>> ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
>>> if (ret)
>>> goto dealloc_usb2_hcd;
>>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>>> index 6700e5e..65a4294 100644
>>> --- a/drivers/usb/host/xhci-plat.c
>>> +++ b/drivers/usb/host/xhci-plat.c
>>> @@ -294,6 +294,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>>> if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
>>> xhci->shared_hcd->can_do_streams = 1;
>>>
>>> + xhci->shared_hcd->skip_phy_initialization = 1;
>>
>> I think this is unnecessary.
>> There aren't separate PHYs for the primary and shared HCDs right?
> Yes, the primary and shared HCDs will get the same PHYs provided by
> "phys" property.
>
>>
>> Also how can you be sure that phy_init() has been done for all platform HCD
>> users?
> Here I assume that "phys" and "usb-phy" properties are not used at the
> same time. There are two cases:
> 1. Using "usb-phy": no "phys" to be got by shared HCD.
> 2. Using "phys": the primary HCD will get those phys, so shared HCD can
> skip them.
Now I see the problem.
But the right fix should be in core/hcd.c
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 2884607..1d1da12 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2757,7 +2757,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
}
- if (!hcd->skip_phy_initialization) {
+ if (!hcd->skip_phy_initialization && usb_hcd_is_primary_hcd(hcd)) {
hcd->phy_roothub = usb_phy_roothub_init(hcd->self.sysdev);
if (IS_ERR(hcd->phy_roothub)) {
retval = PTR_ERR(hcd->phy_roothub);
>
>>
>>> ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
>>> if (ret)
>>> goto dealloc_usb2_hcd;
>>>
>>
>
>
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
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/5] usb: typec: fusb302: remove max_snk_* for sink config
Hi, On 21-03-18 12:19, Jun Li wrote: -Original Message- From: Hans de Goede [mailto:hdego...@redhat.com] Sent: 2018年3月20日 20:29 To: Jun Li ; gre...@linuxfoundation.org; robh...@kernel.org; mark.rutl...@arm.com; heikki.kroge...@linux.intel.com; li...@roeck-us.net; rmf...@gmail.com; yueyao@gmail.com Cc: linux-usb@vger.kernel.org; devicet...@vger.kernel.org; dl-linux-imx Subject: Re: [PATCH 2/5] usb: typec: fusb302: remove max_snk_* for sink config Hi, On 20-03-18 11:26, Li Jun wrote: Since max_snk_* is to be deprecated, so remove max_snk_* by adding a variable PDO for sink config. NACK there are actual users of the device-properties which you are now breaking. As I mentioned in another thread, you need to instead add the pdo array to the fusb302_chip struct (so that it is no longer const) and generate a PDO_VAR pdo based on the device-properties. OK, I did a search of those properties in dts dir of upstream kernel but didn't find any user of them, Note that these properties are not accessed through the dt APIs but through the generic device-properties API. And these are set as device-properties by the driver instantiating the fusb302 i2c-client on (some) x86 boards: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/x86/intel_cht_int33fe.c > if there are actual of users, I will create > a PDO_VAR pdo based on dt in v2. Thank you. Regards, Hans -- 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-next PATCH] usb: xhci: skip phys initialization of shared hcd
Hi Roger, On Wed, 2018-03-21 at 11:05 +0200, Roger Quadros wrote: > Hi Chunfeng, > > On 21/03/18 08:12, Chunfeng Yun wrote: > > The phys has already been initialized when add primary hcd, > > including usb2 phys and usb3 phys also if exist, so needn't > > re-parse "phys" property again. > > > > Signed-off-by: Chunfeng Yun > > --- > > drivers/usb/host/xhci-mtk.c | 1 + > > drivers/usb/host/xhci-plat.c | 1 + > > 2 files changed, 2 insertions(+) > > > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c > > index 7334da9..6bb23fb 100644 > > --- a/drivers/usb/host/xhci-mtk.c > > +++ b/drivers/usb/host/xhci-mtk.c > > @@ -554,6 +554,7 @@ static int xhci_mtk_probe(struct platform_device *pdev) > > if (HCC_MAX_PSA(xhci->hcc_params) >= 4) > > xhci->shared_hcd->can_do_streams = 1; > > > > + xhci->shared_hcd->skip_phy_initialization = 1; > > ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED); > > if (ret) > > goto dealloc_usb2_hcd; > > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c > > index 6700e5e..65a4294 100644 > > --- a/drivers/usb/host/xhci-plat.c > > +++ b/drivers/usb/host/xhci-plat.c > > @@ -294,6 +294,7 @@ static int xhci_plat_probe(struct platform_device *pdev) > > if (HCC_MAX_PSA(xhci->hcc_params) >= 4) > > xhci->shared_hcd->can_do_streams = 1; > > > > + xhci->shared_hcd->skip_phy_initialization = 1; > > I think this is unnecessary. > There aren't separate PHYs for the primary and shared HCDs right? Yes, the primary and shared HCDs will get the same PHYs provided by "phys" property. > > Also how can you be sure that phy_init() has been done for all platform HCD > users? Here I assume that "phys" and "usb-phy" properties are not used at the same time. There are two cases: 1. Using "usb-phy": no "phys" to be got by shared HCD. 2. Using "phys": the primary HCD will get those phys, so shared HCD can skip them. > > > ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED); > > if (ret) > > goto dealloc_usb2_hcd; > > > -- 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-next v10 3/8] usb: core: add a wrapper for the USB PHYs on the HCD
Martin,
On 21/03/18 00:01, Martin Blumenstingl wrote:
> Hi Roger, Hi Chunfeng,
>
> On Tue, Mar 20, 2018 at 1:04 PM, Chunfeng Yun
> wrote:
>> Hi Martin & Roger:
>>
>> On Mon, 2018-03-19 at 17:12 +0100, Martin Blumenstingl wrote:
>>> Hi Roger,
>>>
>>> On Mon, Mar 19, 2018 at 9:49 AM, Roger Quadros wrote:
Hi,
On 19/03/18 00:29, Martin Blumenstingl wrote:
> Hi Roger,
>
> On Fri, Mar 16, 2018 at 3:32 PM, Roger Quadros wrote:
>> +some TI folks
>>
>> Hi Martin,
>>
>> On 18/02/18 20:44, Martin Blumenstingl wrote:
>>> Many SoC platforms have separate devices for the USB PHY which are
>>> registered through the generic PHY framework. These PHYs have to be
>>> enabled to make the USB controller actually work. They also have to be
>>> disabled again on shutdown/suspend.
>>>
>>> Currently (at least) the following HCI platform drivers are using custom
>>> code to obtain all PHYs via devicetree for the roothub/controller and
>>> disable/enable them when required:
>>> - ehci-platform.c has ehci_platform_power_{on,off}
>>> - xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
>>> - ohci-platform.c has ohci_platform_power_{on,off}
>>>
>>> With this new wrapper the USB PHYs can be specified directly in the
>>> USB controller's devicetree node (just like on the drivers listed
>>> above). This allows SoCs like the Amlogic Meson GXL family to operate
>>> correctly once this is wired up correctly. These SoCs use a dwc3
>>> controller and require all USB PHYs to be initialized (if one of the USB
>>> PHYs it not initialized then none of USB port works at all).
>>>
>>> Signed-off-by: Martin Blumenstingl
>>> Tested-by: Yixun Lan
>>> Cc: Neil Armstrong
>>> Cc: Chunfeng Yun
>>
>> This patch is breaking low power cases on TI SoCs when USB is in host
>> mode.
>> I'll explain why below.
> based on your explanation and reading the TI PHY drivers I am assuming
> that the affected SoCs are using the "phy-omap-usb2" driver
>
yes and phy-ti-pipe3 as well i.e. "ti,phy-usb3" and "ti,omap-usb3"
>>> I missed that, thanks
>>>
>>> ---
>>> drivers/usb/core/Makefile | 2 +-
>>> drivers/usb/core/phy.c| 158
>>> ++
>>> drivers/usb/core/phy.h| 7 ++
>>> 3 files changed, 166 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/usb/core/phy.c
>>> create mode 100644 drivers/usb/core/phy.h
>>>
>>> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
>>> index 92c9cefb4317..18e874b0441e 100644
>>> --- a/drivers/usb/core/Makefile
>>> +++ b/drivers/usb/core/Makefile
>>> @@ -6,7 +6,7 @@
>>> usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
>>> usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
>>> usbcore-y += devio.o notify.o generic.o quirks.o devices.o
>>> -usbcore-y += port.o
>>> +usbcore-y += phy.o port.o
>>>
>>> usbcore-$(CONFIG_OF) += of.o
>>> usbcore-$(CONFIG_USB_PCI)+= hcd-pci.o
>>> diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
>>> new file mode 100644
>>> index ..09b7c43c0ea4
>>> --- /dev/null
>>> +++ b/drivers/usb/core/phy.c
>>> @@ -0,0 +1,158 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * A wrapper for multiple PHYs which passes all phy_* function calls to
>>> + * multiple (actual) PHY devices. This is comes handy when initializing
>>> + * all PHYs on a HCD and to keep them all in the same state.
>>> + *
>>> + * Copyright (C) 2018 Martin Blumenstingl
>>>
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#include "phy.h"
>>> +
>>> +struct usb_phy_roothub {
>>> + struct phy *phy;
>>> + struct list_headlist;
>>> +};
>>> +
>>> +static struct usb_phy_roothub *usb_phy_roothub_alloc(struct device
>>> *dev)
>>> +{
>>> + struct usb_phy_roothub *roothub_entry;
>>> +
>>> + roothub_entry = devm_kzalloc(dev, sizeof(*roothub_entry),
>>> GFP_KERNEL);
>>> + if (!roothub_entry)
>>> + return ERR_PTR(-ENOMEM);
>>> +
>>> + INIT_LIST_HEAD(&roothub_entry->list);
>>> +
>>> + return roothub_entry;
>>> +}
>>> +
>>> +static int usb_phy_roothub_add_phy(struct device *dev, int index,
>>> +struct list_head *list)
>>> +{
>>> + struct usb_phy_roothub *roothub_entry;
>>> + struct phy *phy = devm_of_phy_get_by_index(dev, dev->of_node,
>>> index);
>>> +
>>> + if (IS_ERR_OR_NULL(phy)) {
>>> + if (!phy || PTR_ERR(phy) == -ENODEV)
>>> + return 0;
>>> + else
>
RE: [PATCH 2/5] usb: typec: fusb302: remove max_snk_* for sink config
> -Original Message-
> From: Hans de Goede [mailto:hdego...@redhat.com]
> Sent: 2018年3月20日 20:29
> To: Jun Li ; gre...@linuxfoundation.org;
> robh...@kernel.org; mark.rutl...@arm.com;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net; rmf...@gmail.com;
> yueyao@gmail.com
> Cc: linux-usb@vger.kernel.org; devicet...@vger.kernel.org; dl-linux-imx
>
> Subject: Re: [PATCH 2/5] usb: typec: fusb302: remove max_snk_* for sink
> config
>
> Hi,
>
> On 20-03-18 11:26, Li Jun wrote:
> > Since max_snk_* is to be deprecated, so remove max_snk_* by adding a
> > variable PDO for sink config.
>
> NACK there are actual users of the device-properties which you are now
> breaking. As I mentioned in another thread, you need to instead add the pdo
> array to the fusb302_chip struct (so that it is no longer
> const) and generate a PDO_VAR pdo based on the device-properties.
>
OK, I did a search of those properties in dts dir of upstream kernel
but didn't find any user of them, if there are actual of users, I will create
a PDO_VAR pdo based on dt in v2.
Thanks
Jun Li
> Regards,
>
> Hans
>
>
> >
> > Signed-off-by: Li Jun
> > ---
> > drivers/usb/typec/fusb302/fusb302.c | 13 +
> > 1 file changed, 1 insertion(+), 12 deletions(-)
> >
> > diff --git a/drivers/usb/typec/fusb302/fusb302.c
> > b/drivers/usb/typec/fusb302/fusb302.c
> > index da179aa..c183f46 100644
> > --- a/drivers/usb/typec/fusb302/fusb302.c
> > +++ b/drivers/usb/typec/fusb302/fusb302.c
> > @@ -1207,6 +1207,7 @@ static const u32 src_pdo[] = {
> >
> > static const u32 snk_pdo[] = {
> > PDO_FIXED(5000, 400, PDO_FIXED_FLAGS),
> > + PDO_VAR(800, 5000, 3000),
> > };
> >
> > static const struct tcpc_config fusb302_tcpc_config = { @@ -1214,9
> > +1215,6 @@ static const struct tcpc_config fusb302_tcpc_config = {
> > .nr_src_pdo = ARRAY_SIZE(src_pdo),
> > .snk_pdo = snk_pdo,
> > .nr_snk_pdo = ARRAY_SIZE(snk_pdo),
> > - .max_snk_mv = 5000,
> > - .max_snk_ma = 3000,
> > - .max_snk_mw = 15000,
> > .operating_snk_mw = 2500,
> > .type = TYPEC_PORT_DRP,
> > .default_role = TYPEC_SINK,
> > @@ -1784,15 +1782,6 @@ static int fusb302_probe(struct i2c_client
> *client,
> > chip->tcpc_dev.config = &chip->tcpc_config;
> > mutex_init(&chip->lock);
> >
> > - if (!device_property_read_u32(dev, "fcs,max-sink-microvolt", &v))
> > - chip->tcpc_config.max_snk_mv = v / 1000;
> > -
> > - if (!device_property_read_u32(dev, "fcs,max-sink-microamp", &v))
> > - chip->tcpc_config.max_snk_ma = v / 1000;
> > -
> > - if (!device_property_read_u32(dev, "fcs,max-sink-microwatt", &v))
> > - chip->tcpc_config.max_snk_mw = v / 1000;
> > -
> > if (!device_property_read_u32(dev, "fcs,operating-sink-microwatt", &v))
> > chip->tcpc_config.operating_snk_mw = v / 1000;
> >
> >
RE: [PATCH 1/5] usb: typec: tcpm: source pdo selection update
Hi > -Original Message- > From: Hans de Goede [mailto:hdego...@redhat.com] > Sent: 2018年3月20日 20:27 > To: Jun Li ; gre...@linuxfoundation.org; > robh...@kernel.org; mark.rutl...@arm.com; > heikki.kroge...@linux.intel.com; li...@roeck-us.net; rmf...@gmail.com; > yueyao@gmail.com > Cc: linux-usb@vger.kernel.org; devicet...@vger.kernel.org; dl-linux-imx > > Subject: Re: [PATCH 1/5] usb: typec: tcpm: source pdo selection update > > Hi, > > On 20-03-18 11:26, Li Jun wrote: > > Instead of only compare between the same pdo type of sink and source, > > this patch update the source pdo selection by checking the source pdo > > voltage range is within that of sink. > > > > Signed-off-by: Li Jun > > This patch applies on top of the broken reverted commit, but the revert has > already been merged by Linus: > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ke > rnel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2 > Fcommit%2Fdrivers%2Fusb%2Ftypec%3Fid%3D6f566af3462897fc743e3af6ea > 8cc790a13148ba&data=02%7C01%7Cjun.li%40nxp.com%7C188f2cdfa5eb44af > d27808d58e5dd13c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7 > C636571455959361056&sdata=CjnsG0rxIfJnm0K2tQyDbFxIP4Als%2BTT243Fh > y7UYyI%3D&reserved=0 > > This commit is not in usb-next because it went into 4.16 as fix after > 4.16-rc1. > As already mentioned in another rhread this needs to be back-merged into > usb-next. > > So this needs to be respun to apply on top of the revert so that it can be > merged without issues with Torvald's tree later. OK, I will do the rebase in v2. Thanks Jun
RE: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow
Hi Minas: >-Original Message- >From: Minas Harutyunyan [mailto:minas.harutyun...@synopsys.com] >Sent: Wednesday, March 21, 2018 4:08 PM >To: Zengtao (B) ; Minas Harutyunyan >; John Youn ; >Felipe Balbi ; Greg Kroah-Hartman >; linux-usb@vger.kernel.org >Subject: Re: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow > >Hi Zengtao, > >On 3/21/2018 6:17 AM, Zengtao (B) wrote: >>> -Original Message- >> >>> From: linux-usb-ow...@vger.kernel.org >> >>> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Minas >>> Harutyunyan >> >>> Sent: Tuesday, March 20, 2018 10:40 PM >> >>> To: Zengtao (B) ; Minas Harutyunyan >> >>> ; John Youn >; >> >>> Felipe Balbi ; Greg Kroah-Hartman >> >>> ; linux-usb@vger.kernel.org >> >>> Subject: Re: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow >> >>> >> >>> Hi Zengtao, >> >>> >> >>> On 3/20/2018 6:01 AM, Zengtao (B) wrote: >> Hi Minas: >> >> >> >> A few minor comments: >> >> >> >> > -Original Message- >> >> > From: linux-usb-ow...@vger.kernel.org >> >> > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Minas >> > Harutyunyan >> >> > Sent: Saturday, March 17, 2018 5:10 PM >> >> > To: John Youn ; Felipe Balbi >> > ; >> >> > Greg Kroah-Hartman ; >> > linux-usb@vger.kernel.org >> >> > Cc: Minas Harutyunyan >> >> > Subject: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow >> >> > >> >> > Changed existing two descriptor-chain flow to one chain. >> >> > >> >> > In two-chain implementation BNA interrupt used for switching > between >> > two >> >> > chains. BNA interrupt asserted because of returning to beginning of >> > the chain >> >> > based on L-bit of last descriptor. >> >> > >> >> > Because of that we lose packets. This issue resolved by using one >desc-chain. >> >> > >> >> > Removed all staff related to two desc-chain flow from DDMA ISOC >> > related >> >> > functions. >> >> > >> >> > Removed request length checking from dwc2_gadget_fill_isoc_desc() >> >>> function. >> >> > Request length checking added to dwc2_hsotg_ep_queue() function. If >> > request >> >> > length greater than descriptor limits then request not added to queue. >> >> > Additional checking done for High Bandwidth ISOC OUT's which not >> > supported by >> >> > driver. In >> >> > dwc2_gadget_fill_isoc_desc() function also checked desc-chain > status >> > (full or not) >> >> > to avoid of reusing not yet processed descriptors. >> >> > >> >> > In dwc2_gadget_start_isoc_ddma() function creation of desc-chain >> > always >> >> > started from descriptor 0. Before filling descriptors, they were >> > initialized by >> >> > HOST BUSY status. >> >> > >> >> > In dwc2_gadget_complete_isoc_request_ddma() added checking for >> > desc-chain >> >> > rollover. Also added checking completion status. >> >> > Request completed successfully if DEV_DMA_STS is DEV_DMA_STS_SUCC, >> >> > otherwise complete with -ETIMEDOUT. >> >> > >> >> > Actually removed dwc2_gadget_start_next_isoc_ddma() function > because >> > now >> >> > driver use only one desc-chain and instead that function added >> >> > dwc2_gadget_handle_isoc_bna() function for handling BNA interrupts. >> >> > >> >> > Handling BNA interrupt done by flushing TxFIFOs for OUT EPs, >> > completing >> >> > request with -EIO and resetting desc-chain number and target frame > to >> > initial >> >> > values for restarting transfers. >> >> > >> >> > On handling NAK request completed with -ENODATA. Incremented target >> > frame >> >> > to allow fill desc chain and start transfers. >> >> > In DDMA mode avoided of frame number incrementing, because tracking >> > of >> >> > frame number performed in dwc2_gadget_fill_isoc_desc() function. >> >> > >> >> > When core assert XferCompl along with BNA, we should ignore > XferCompl >> > in >> >> > dwc2_hsotg_epint() function. >> >> > >> >> > On BNA interrupt replaced dwc2_gadget_start_next_isoc_ddma() by > above >> >> > mentioned BNA handler. >> >> > >> >> > In dwc2_hsotg_ep_enable() function added sanity check of bInterval >> > for ISOC IN >> >> > in DDMA mode, because HW not supported EP's with bInterval more than >12. >> >> > >> >> > Signed-off-by: Minas Harutyunyan >> >> > --- >> >> > drivers/usb/dwc2/core.h | 2 - >> >> > drivers/usb/dwc2/gadget.c | 235 >> > ++ >> >> >
[PATCH v4] usb/gadget/uvc-configs Fix host unable to negotiate framesizes other than first
- Add bFrameIndex as a UVCG_FRAME_ATTR_RO for each frame size.
- Automatically assign ascending bFrameIndex to each frame in a format.
Before all "bFrameindex" attributes were set to "1" with no way to
configure the gadget otherwise. This resulted in the host always
negotiating for bFrameIndex 1 (i.e. the first framesize of the gadget).
After the negotiation the host driver will set the user or application
selected framesize, while the gadget is actually set to the first
framesize.
Now, when the containing format is linked into the streaming header,
iterate over all child frame descriptors and assign ascending indices.
The automatically assigned indices can be read from the new read only
bFrameIndex configsfs attribute in each frame descriptor item.
v2: Add the new attribute to both MJPEG and uncompressed frame descriptors
in Documentation/ABI, with note that it was added only in a later
kernel version
v3: Changed from simply allowing user to set the value for bFrameIndex to
automatically assigning correct distinct frame indexes. Changed
bFrameIndex from RW to RO
v4: Actually include updated patch
Signed-off-by: Joel Pepper
---
Documentation/ABI/testing/configfs-usb-gadget-uvc | 18
drivers/usb/gadget/function/uvc_configfs.c| 53 +++
2 files changed, 71 insertions(+)
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc
b/Documentation/ABI/testing/configfs-usb-gadget-uvc
index 1ba0d0f..872ed8a 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
@@ -194,6 +194,14 @@ Description: Specific MJPEG frame descriptors
bmCapabilities - still image support, fixed frame-rate
support
+Date: Mar 2018
+KernelVersion: 4.16
+
+ bFrameIndex - unique id for this framedescriptor;
+ only defined after parent format is
+ linked into the streaming header;
+ read-only
+
What:
/config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed
Date: Dec 2014
KernelVersion: 4.0
@@ -241,6 +249,16 @@ Description: Specific uncompressed frame descriptors
bmCapabilities - still image support, fixed frame-rate
support
+Date: Mar 2018
+KernelVersion: 4.16
+
+bFrameIndex - unique id for this framedescriptor;
+only defined after parent format is
+linked into the streaming header;
+read-only
+
+
+
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/header
Date: Dec 2014
KernelVersion: 4.0
diff --git a/drivers/usb/gadget/function/uvc_configfs.c
b/drivers/usb/gadget/function/uvc_configfs.c
index c9b8cc4a..a73dbc5 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -32,6 +32,7 @@ static struct configfs_attribute prefix##attr_##cname = { \
}
static inline struct f_uvc_opts *to_f_uvc_opts(struct config_item *item);
+static void __uvcg_fmt_set_indices(struct config_group* fmt);
/* control/header/ */
DECLARE_UVC_HEADER_DESCRIPTOR(1);
@@ -751,6 +752,8 @@ static int uvcg_streaming_header_allow_link(struct
config_item *src,
if (!target_fmt)
goto out;
+ __uvcg_fmt_set_indices(to_config_group(target));
+
format_ptr = kzalloc(sizeof(*format_ptr), GFP_KERNEL);
if (!format_ptr) {
ret = -ENOMEM;
@@ -929,6 +932,30 @@ static struct uvcg_frame *to_uvcg_frame(struct config_item
*item)
return container_of(item, struct uvcg_frame, item);
}
+#define UVCG_FRAME_ATTR_RO(cname, aname, to_cpu_endian, to_little_endian,
bits) \
+static ssize_t uvcg_frame_##cname##_show(struct config_item *item, char *page)\
+{ \
+ struct uvcg_frame *f = to_uvcg_frame(item); \
+ struct f_uvc_opts *opts;\
+ struct config_item *opts_item; \
+ struct mutex *su_mutex = &f->item.ci_group->cg_subsys->su_mutex;\
+ int result; \
+ \
+ mutex_lock(su_mutex); /* for navigating configfs hierarchy */ \
+ \
+ opts_item = f->item.ci_parent->ci_parent->ci_parent->ci_parent; \
+ opts = to_f_uvc_opts(opts_item);\
+ \
+ mutex_lock(&opts->lock);
Re: [PATCH] usb/gadget/uvc-configs Fix host unable to negotiate framesizes other than first
Hi Joel, On Wednesday, 21 March 2018 11:53:45 EET Joel Pepper wrote: > Hi Laurent, > > Thanks for the heads up. I noticed the goof with Patch v3 right after > sending, but apparently I screwed up the commit amend too. I'm still > getting accustomed to kernel development. Sorry for wasting your time, I > will have v4 along shortly If the result is that you become more familiar with kernel development and keep contributing I'll consider this as time well invested, not wasted. -- 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/gadget/uvc-configs Fix host unable to negotiate framesizes other than first
Hi Joel,
Thank you for the patch.
On Tuesday, 20 March 2018 22:28:53 EET Joel Pepper wrote:
> - Add bFrameIndex as a UVCG_FRAME_ATTR_RO for each frame size.
> - Automatically assign ascending bFrameIndex to each frame in a format.
>
> Before all "bFrameindex" attributes were set to "1" with no way to
> configure the gadget otherwise. This resulted in the host always
> negotiating for bFrameIndex 1 (i.e. the first framesize of the gadget).
> After the negotiation the host driver will set the user or application
> selected framesize, while the gadget is actually set to the first
> framesize.
>
> Now, when the containing format is linked into the streaming header,
> iterate over all child frame descriptors and assign ascending indices.
> The automatically assigned indices can be read from the new read only
> bFrameIndex configsfs attribute in each frame descriptor item.
>
> v2: Add the new attribute to both MJPEG and uncompressed frame descriptors
> in Documentation/ABI, with note that it was added only in a later
> kernel version
>
> v3: Changed from simply allowing user to set the value for bFrameIndex to
> automatically assigning correct distinct frame indexes. Changed
> bFrameIndex from RW to RO
I like the new commit message, but it would be nice if you could also update
the patch contents ;-)
(By the way the subject line should have mentioned "[PATCH v3]")
> Signed-off-by: Joel Pepper
> ---
> Documentation/ABI/testing/configfs-usb-gadget-uvc | 17 +
> drivers/usb/gadget/function/uvc_configfs.c| 3 +++
> 2 files changed, 20 insertions(+)
>
> diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc
> b/Documentation/ABI/testing/configfs-usb-gadget-uvc index 1ba0d0f..d435cf7
> 100644
> --- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
> +++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
> @@ -194,6 +194,14 @@ Description: Specific MJPEG frame descriptors
> bmCapabilities - still image support, fixed frame-rate
> support
>
> +Date:Mar 2018
> +KernelVersion: 4.16
> +
> + bFrameIndex - unique id for this framedescriptor;
> + if using multiple framedescriptors for
> + same format, user needs to set distinct
> + value for each frame descriptor
> +
> What:/config/usb-gadget/gadget/functions/uvc.name/streaming/
uncompressed
> Date:Dec 2014
> KernelVersion: 4.0
> @@ -241,6 +249,15 @@ Description: Specific uncompressed frame descriptors
> bmCapabilities - still image support, fixed frame-rate
> support
>
> +Date: Mar 2018
> +KernelVersion: 4.16
> +
> +bFrameIndex - unique id for this
> framedescriptor; +if using multiple
> framedescriptors for +same format,
> user needs to set distinct +value
> for each frame descriptor +
> +
> What:
> /config/usb-gadget/gadget/functions/uvc.name/streaming/header
> Date:Dec 2014
> KernelVersion: 4.0
> diff --git a/drivers/usb/gadget/function/uvc_configfs.c
> b/drivers/usb/gadget/function/uvc_configfs.c index c9b8cc4a..5966d65 100644
> --- a/drivers/usb/gadget/function/uvc_configfs.c
> +++ b/drivers/usb/gadget/function/uvc_configfs.c
> @@ -992,6 +992,8 @@ UVC_ATTR(uvcg_frame_, cname, aname);
>
> UVCG_FRAME_ATTR(bm_capabilities, bmCapabilities, noop_conversion,
> noop_conversion, 8);
> +UVCG_FRAME_ATTR(b_frame_index, bFrameIndex, noop_conversion,
> + noop_conversion, 8);
> UVCG_FRAME_ATTR(w_width, wWidth, le16_to_cpu, cpu_to_le16, 16);
> UVCG_FRAME_ATTR(w_height, wHeight, le16_to_cpu, cpu_to_le16, 16);
> UVCG_FRAME_ATTR(dw_min_bit_rate, dwMinBitRate, le32_to_cpu, cpu_to_le32,
> 32); @@ -1137,6 +1139,7 @@ UVC_ATTR(uvcg_frame_, dw_frame_interval,
> dwFrameInterval);
>
> static struct configfs_attribute *uvcg_frame_attrs[] = {
> &uvcg_frame_attr_bm_capabilities,
> + &uvcg_frame_attr_b_frame_index,
> &uvcg_frame_attr_w_width,
> &uvcg_frame_attr_w_height,
> &uvcg_frame_attr_dw_min_bit_rate,
--
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: [PATCHv2] usb/gadget/uvc-configs Fix host unable to negotiate framesizes other than first
Hi Joel, On Tuesday, 20 March 2018 12:30:00 EET Joel Pepper wrote: > On 20.03.2018 10:02, Laurent Pinchart wrote: > > Hi Joel, > > > > (CC'ing Paul Elder who is working on the UVC gadget driver) > > > > Thank you for the patch. > > > > On Monday, 19 March 2018 21:36:41 EET Joel Pepper wrote: > >> Add bFrameIndex as a UVCG_FRAME_ATTR for each frame size. > >> Before all "bFrameindex" attributes were set to "1" with no way to > >> configure the gadget otherwise. This resulted in the host always > >> negotiating for bFrameIndex 1 (i.e. the first framesize of the gadget). > >> After the negotiation the host driver will set the user or application > >> selected framesize, while the gadget is actually set to the first > >> framesize. > >> > >> Note that this still requires the gadget to be configured with unique > >> bFrameIndexes for each frameSize of each format through configfs. An > >> alternative might be to automatically assign ascending indices when the > >> format is linked into the streaming header, but the user space gadget > >> would need a way to check or predict the indices so that it can properly > >> interpret to PROBE/COMMIT CONTROL requests > > > > It would indeed be nice if the indices could be automatically generated, > > to avoid giving userspace another possibility to create invalid > > descriptors. As you've correctly noted, that would require a way for the > > userspace helper application to coordinate with the UVC gadget driver. > > Would it be difficult to do so by defining the bFrameIndex attribute as > > read-only ? There's the additional issue of finding a place to store the > > index counter locally to the format, I'm not sure how that's done with the > > configfs API, but if it's not too difficult I think it would be a good > > option. > > Setting bFrameIndex to be read-only will suffice in allowing the > userspace gadget to coordinate with the driver at the (slight) expense of > the userspace gadget not being able to dictate an order which is > semantically meaningful to it. > > There are two approaches I see towards assigning indices automatically: > 1) Assign a new unique index in "uvcg_frame_make" (i.e. config item > creation) > 2) Assign indices when exact set of frame descriptors is finalized (i.e. > linking into the streaming header) > > As for 1): > I think this is the approach you are referring to with regards to > storing the index counter in the format. There already is a 'num_frames' > unsigned int in the uvcg_format struct, which could be used as index, > however this approach does not handle deleting frame descriptors well, > because num_frames is decremented then. Unless frames are always deleted in > reverse order of creation this will produce index collisions. If we instead > use a new monotonously incrementing counter, deleting frames will produce > "holes" in the indices (I think UVC does allow for that but it might trip > up host drivers not expecting that). The counter would also overflow after > creating 255 frames even if the final number is much lower. > > > As for 2): > I personally prefer this approach as it avoids the problems of 1). It > depends on identifying a point in time when the set of frame descriptors > cannot change anymore I think this is given when the format is linked into > the streaming header. It should then suffice to iterate of the contained > frames and assign ascending indices. A small problem however is that the > attribute will have no meaningful value to be read before the format is > linked. This fact will need to be communicated in the documentation and > potentially through returning EBUSY on premature read attempts. > > I'll prepare a patch implementing 2), but in the meantime I'm grateful > for more input, as there is not necessarily a single best approach to be > taken here. I like the second approach for the reasons you've described above. Returning -EBUSY might not even be necessary, as before the gadget is fully setup there will be no V4L2 device registered anyway, and the userspace helper application will thus not be able to proceed. It however seems a good idea to let userspace know that the attribute isn't ready yet, so I agree with your proposal. > >> v2: Add the new attribute to both MJPEG and uncompressedframe descriptos > >> in Documentation/ABI, with note that it was added only in a later > >> kernel version > >> > >> Signed-off-by: Joel Pepper > >> --- > >> > >> Documentation/ABI/testing/configfs-usb-gadget-uvc | 17 + > >> drivers/usb/gadget/function/uvc_configfs.c| 3 +++ > >> 2 files changed, 20 insertions(+) > >> > >> diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc > >> b/Documentation/ABI/testing/configfs-usb-gadget-uvc index > >> 1ba0d0f..d435cf7 > >> 100644 > >> --- a/Documentation/ABI/testing/configfs-usb-gadget-uvc > >> +++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc > >> @@ -194,6 +194,14 @@ Description: Specific MJPEG frame descripto
Re: [PATCH v1 0/3] usb: dwc2: gadget: Update ISOC DDMA flow.
Hi Filipe, On 3/17/2018 1:08 PM, Minas Harutyunyan wrote: > This series fully update existing ISOC DDMA flow which initially based on > 2 descriptor chains. Switching between desc chains performing based on BNA > interrupt. Because of BNA interrupt few packets can be lost. > > 1/3 patch unmask ISOC IN BNA interrupt only. > 2/3 patch changing ISOC IN/OUT flow as described above. > 3/3 patch add High bandwidth ISOC OUT transfers support. > > All patches were tested on HAPS-DX7 platform using internal USB test tool. > > Changes from version 0: > > Fix kbuild test robot warnings on idents. > > > Minas Harutyunyan (3): >usb: dwc2: Enable BNA interrupt for IN endpoints >usb: dwc2: Change ISOC DDMA flow >usb: dwc2: Add High Bandwidth ISOC OUT support > > drivers/usb/dwc2/core.h | 2 - > drivers/usb/dwc2/gadget.c | 505 > -- > 2 files changed, 359 insertions(+), 148 deletions(-) > I need your advise on this patch series. My question is related to requests completion codes in different cases. In patch series I used follow completion codes: 1. In case of BNA. Request completed with status code -EIO; 2. In case of IN-NAK and OUT-EPDis. Request completed with status code -NODATA; 3. In case of XferComplete. Request completed with status code -NODATA or -ETIMEDOUT depend on descriptor error status: buffer flush, uf number, DPID's, etc. Are these status codes acceptable from function driver point of view? Or maybe dwc2 should complete the requests for above cases with "0" status code and function driver should rely on actual data size, not on completion code? Thanks, Minas -- 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-next PATCH] usb: xhci: skip phys initialization of shared hcd
Hi Chunfeng, On 21/03/18 08:12, Chunfeng Yun wrote: > The phys has already been initialized when add primary hcd, > including usb2 phys and usb3 phys also if exist, so needn't > re-parse "phys" property again. > > Signed-off-by: Chunfeng Yun > --- > drivers/usb/host/xhci-mtk.c | 1 + > drivers/usb/host/xhci-plat.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c > index 7334da9..6bb23fb 100644 > --- a/drivers/usb/host/xhci-mtk.c > +++ b/drivers/usb/host/xhci-mtk.c > @@ -554,6 +554,7 @@ static int xhci_mtk_probe(struct platform_device *pdev) > if (HCC_MAX_PSA(xhci->hcc_params) >= 4) > xhci->shared_hcd->can_do_streams = 1; > > + xhci->shared_hcd->skip_phy_initialization = 1; > ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED); > if (ret) > goto dealloc_usb2_hcd; > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c > index 6700e5e..65a4294 100644 > --- a/drivers/usb/host/xhci-plat.c > +++ b/drivers/usb/host/xhci-plat.c > @@ -294,6 +294,7 @@ static int xhci_plat_probe(struct platform_device *pdev) > if (HCC_MAX_PSA(xhci->hcc_params) >= 4) > xhci->shared_hcd->can_do_streams = 1; > > + xhci->shared_hcd->skip_phy_initialization = 1; I think this is unnecessary. There aren't separate PHYs for the primary and shared HCDs right? Also how can you be sure that phy_init() has been done for all platform HCD users? > ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED); > if (ret) > goto dealloc_usb2_hcd; > -- cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki -- 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 v1 2/3] usb: dwc2: Change ISOC DDMA flow
Hi Zengtao, On 3/21/2018 6:17 AM, Zengtao (B) wrote: >> -Original Message- > >> From: linux-usb-ow...@vger.kernel.org > >> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Minas Harutyunyan > >> Sent: Tuesday, March 20, 2018 10:40 PM > >> To: Zengtao (B) ; Minas Harutyunyan > >> ; John Youn ; > >> Felipe Balbi ; Greg Kroah-Hartman > >> ; linux-usb@vger.kernel.org > >> Subject: Re: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow > >> > >> Hi Zengtao, > >> > >> On 3/20/2018 6:01 AM, Zengtao (B) wrote: > >>> Hi Minas: > >>> > >>> > >>> > >>> A few minor comments: > >>> > >>> > >>> > -Original Message- > >>> > From: linux-usb-ow...@vger.kernel.org > >>> > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Minas > Harutyunyan > >>> > Sent: Saturday, March 17, 2018 5:10 PM > >>> > To: John Youn ; Felipe Balbi > ; > >>> > Greg Kroah-Hartman ; > linux-usb@vger.kernel.org > >>> > Cc: Minas Harutyunyan > >>> > Subject: [PATCH v1 2/3] usb: dwc2: Change ISOC DDMA flow > >>> > > >>> > Changed existing two descriptor-chain flow to one chain. > >>> > > >>> > In two-chain implementation BNA interrupt used for switching between > two > >>> > chains. BNA interrupt asserted because of returning to beginning of > the chain > >>> > based on L-bit of last descriptor. > >>> > > >>> > Because of that we lose packets. This issue resolved by using one desc-chain. > >>> > > >>> > Removed all staff related to two desc-chain flow from DDMA ISOC > related > >>> > functions. > >>> > > >>> > Removed request length checking from dwc2_gadget_fill_isoc_desc() > >> function. > >>> > Request length checking added to dwc2_hsotg_ep_queue() function. If > request > >>> > length greater than descriptor limits then request not added to queue. > >>> > Additional checking done for High Bandwidth ISOC OUT's which not > supported by > >>> > driver. In > >>> > dwc2_gadget_fill_isoc_desc() function also checked desc-chain status > (full or not) > >>> > to avoid of reusing not yet processed descriptors. > >>> > > >>> > In dwc2_gadget_start_isoc_ddma() function creation of desc-chain > always > >>> > started from descriptor 0. Before filling descriptors, they were > initialized by > >>> > HOST BUSY status. > >>> > > >>> > In dwc2_gadget_complete_isoc_request_ddma() added checking for > desc-chain > >>> > rollover. Also added checking completion status. > >>> > Request completed successfully if DEV_DMA_STS is DEV_DMA_STS_SUCC, > >>> > otherwise complete with -ETIMEDOUT. > >>> > > >>> > Actually removed dwc2_gadget_start_next_isoc_ddma() function because > now > >>> > driver use only one desc-chain and instead that function added > >>> > dwc2_gadget_handle_isoc_bna() function for handling BNA interrupts. > >>> > > >>> > Handling BNA interrupt done by flushing TxFIFOs for OUT EPs, > completing > >>> > request with -EIO and resetting desc-chain number and target frame to > initial > >>> > values for restarting transfers. > >>> > > >>> > On handling NAK request completed with -ENODATA. Incremented target > frame > >>> > to allow fill desc chain and start transfers. > >>> > In DDMA mode avoided of frame number incrementing, because tracking > of > >>> > frame number performed in dwc2_gadget_fill_isoc_desc() function. > >>> > > >>> > When core assert XferCompl along with BNA, we should ignore XferCompl > in > >>> > dwc2_hsotg_epint() function. > >>> > > >>> > On BNA interrupt replaced dwc2_gadget_start_next_isoc_ddma() by above > >>> > mentioned BNA handler. > >>> > > >>> > In dwc2_hsotg_ep_enable() function added sanity check of bInterval > for ISOC IN > >>> > in DDMA mode, because HW not supported EP's with bInterval more than 12. > >>> > > >>> > Signed-off-by: Minas Harutyunyan > >>> > --- > >>> > drivers/usb/dwc2/core.h | 2 - > >>> > drivers/usb/dwc2/gadget.c | 235 > ++ > >>> > 2 files changed, 113 insertions(+), 124 deletions(-) > >>> > > >>> > diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h index > >>> > d83be5651f87..093d078adaf4 100644 > >>> > --- a/drivers/usb/dwc2/core.h > >>> > +++ b/drivers/usb/dwc2/core.h > >>> > @@ -178,7 +178,6 @@ struct dwc2_hsotg_req; > >>> > * @desc_list_dma: The DMA address of descriptor chain currently in use. > >>> > * @desc_list: Pointer to descriptor DMA chain head currently in use. > >>> >
