Can Only Enable 2 Classes Using Gadget ConfigFS
The attached script works only when 2 of the 3 given classes are
enabled. The failure is that UDC is not writeable. Is there a limit I
am reaching? I did not think I would get to 32 endpoints, so is there
a limitation due to my device's construction?
I can not find any good troubleshooting information.
Thanks in advance,
R0b0t1
---
#!/bin/bash
set -euo pipefail
# General configuration:
GADGET_NAME="testgadget"
LANGUAGE=0x409
MANUFACTURER="Sidney Spry"
PRODUCT="Test Gadget"
# Function configuration:
HOST_ADDRESS="1a:55:89:a2:69:42"
DEV_ADDRESS="1a:55:89:a2:69:41"
if [ "$EUID" -ne 0 ]; then
echo "This script must run as root."
exit 1
fi
echo "Loading libcomposite..."
CONFIGFS="/sys/kernel/config/usb_gadget"
GADGET="$CONFIGFS/$GADGET_NAME"
modprobe libcomposite
while [ ! -d $CONFIGFS ]; do
sleep 0.01
done
echo "Cleaning existing gadget..."
find $GADGET/configs/*/* -maxdepth 0 -type l -exec rm {} \; || true
find $GADGET/configs/*/strings/* -maxdepth 0 -type d -exec rmdir {} \; || true
find $GADGET/os_desc/* -maxdepth 0 -type l -exec rm {} \; || true
find $GADGET/functions/* -maxdepth 0 -type d -exec rmdir {} \; || true
find $GADGET/strings/* -maxdepth 0 -type d -exec rmdir {} \; || true
find $GADGET/configs/* -maxdepth 0 -type d -exec rmdir {} \; || true
rmdir $GADGET || true
#find "$GADGET/configs" -maxdepth 2 -type l -exec "rm" {} \;
#find "$GADGET"/configs/*/strings/* -maxdepth 0 -type d -exec "rmdir" {} \;
#find "$GADGET"/os_desc/* -maxdepth 0 -type l -exec "rm" {} \;
#find "$GADGET"/configs/functions/* -maxdepth 0 -type d -exec "rmdir" {} \;
#find "$GADGET"/configs/* -maxdepth 0 -type d -exec "rmdir" {} \;
#rmdir "$GADGET"
echo "Creating gadget..."
mkdir "$GADGET"
cd "$GADGET"
echo "Configuring device identifiers..."
echo 0x1d6b > idVendor # Linux Foundation
echo 0x0104 > idProduct # Multifunction Composite Gadget
echo 0x0001 > bcdDevice # v0.1.0
echo 0x0200 > bcdUSB# USB 2.0
mkdir "strings/$LANGUAGE"
echo "$MANUFACTURER" > "strings/$LANGUAGE/manufacturer"
echo "$PRODUCT" > "strings/$LANGUAGE/product"
echo "Configuring composite device..."
echo 0xEF > bDeviceClass
echo 0x02 > bDeviceSubClass
echo 0x01 > bDeviceProtocol
echo "Configuring OS-specific descriptors..."
echo 1 > os_desc/use
echo 0xcd> os_desc/b_vendor_code
echo MSFT100 > os_desc/qw_sign
echo "Creating Ethernet endpoint (CDC NCM) (1/1)..."
mkdir "functions/ncm.usb0"
#echo "$HOST_ADDRESS" > "functions/ncm.usb0/host_addr"
#echo "$DEV_ADDRESS" > "functions/ncm.usb0/dev_addr"
echo "Creating serial endpoint (1/2)..."
mkdir "functions/acm.usb0"
echo "Creating serial endpoint (2/2)..."
mkdir "functions/acm.usb1"
echo "Creating configuration..."
mkdir "configs/c.1"
echo 500 > "configs/c.1/MaxPower"
mkdir "configs/c.1/strings/$LANGUAGE"
echo "Config 1" > "configs/c.1/strings/$LANGUAGE/configuration"
ln -s "functions/ncm.usb0" "configs/c.1"
ln -s "functions/acm.usb0" "configs/c.1"
ln -s "functions/acm.usb1" "configs/c.1"
ln -s "configs/c.1" "os_desc/c.1"
echo "Attaching device..."
udevadm settle
ls "/sys/class/udc/" > UDC
echo "Done."
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: gadget: uvc: configfs: Add bFrameIndex attributes
@Laurent, I accidentally hit "Reply" instead of "Reply All", please
disregard the previous copy of this email
Hi Laurent and Paul,
On 08.06.2018 21:16, Laurent Pinchart wrote:
> Hi Joel and Paul,
>
> On Friday, 8 June 2018 22:12:56 EEST Laurent Pinchart wrote:
>> From: Paul Elder
>>
>> The UVC frame descriptions are numbered using the descriptor's
>> bFrameIndex field. The index is used in UVC requests, and is thus
>> needed to handle requests in userspace. Make it dynamically discoverable
>> by exposing it in a bFrameIndex configfs attribute of the frame
>> config item.
>>
>> However, the bFrameIndex value is never set to begin with. Set these
>> values when linking the stream class header in the configfs hierarchy,
>> and store it in the config item private data.
>>
>> Signed-off-by: Paul Elder
>> ---
>> drivers/usb/gadget/function/uvc_configfs.c | 10 --
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/uvc_configfs.c
>> b/drivers/usb/gadget/function/uvc_configfs.c index
>> 0ad6ea57d0b7..882d9963b244 100644
>> --- a/drivers/usb/gadget/function/uvc_configfs.c
>> +++ b/drivers/usb/gadget/function/uvc_configfs.c
>> @@ -1152,6 +1152,8 @@ UVC_ATTR(uvcg_frame_, cname, aname);
>>
>> #define noop_conversion(x) (x)
>>
>> +UVCG_FRAME_ATTR_RO(b_frame_index, bFrameIndex, noop_conversion,
>> +noop_conversion, 8);
>> UVCG_FRAME_ATTR(bm_capabilities, bmCapabilities, noop_conversion,
>> noop_conversion, 8);
>> UVCG_FRAME_ATTR(w_width, wWidth, le16_to_cpu, cpu_to_le16, 16);
>> @@ -1298,6 +1300,7 @@ static ssize_t
>> uvcg_frame_dw_frame_interval_store(struct config_item *item,
>> UVC_ATTR(uvcg_frame_, dw_frame_interval, dwFrameInterval);
>>
>> static struct configfs_attribute *uvcg_frame_attrs[] = {
>> +&uvcg_frame_attr_b_frame_index,
>> &uvcg_frame_attr_bm_capabilities,
>> &uvcg_frame_attr_w_width,
>> &uvcg_frame_attr_w_height,
>> @@ -2130,12 +2133,15 @@ static int __uvcg_fill_strm(void *priv1, void
>> *priv2, void *priv3, int n, sizeof(*frm->dw_frame_interval);
>> memcpy(*dest, frm->dw_frame_interval, sz);
>> *dest += sz;
>> -if (frm->fmt_type == UVCG_UNCOMPRESSED)
>> +if (frm->fmt_type == UVCG_UNCOMPRESSED) {
>> h->bLength = UVC_DT_FRAME_UNCOMPRESSED_SIZE(
>> frm->frame.b_frame_interval_type);
>> -else if (frm->fmt_type == UVCG_MJPEG)
>> +frm->frame.b_frame_index = n + 1;
>> +} else if (frm->fmt_type == UVCG_MJPEG) {
>> h->bLength = UVC_DT_FRAME_MJPEG_SIZE(
>> frm->frame.b_frame_interval_type);
>> +frm->frame.b_frame_index = n + 1;
>> +}
>> }
>> break;
>> }
>
> This approach looks simpler to me than the patch that Joel submitted.
However,
> this patch lacks ABI documentation, which is included in Joel's patch.
>
> Joel, as you were first, I propose taking your patch and modifying it
with the
> approach followed here, using the UVCG_FRAME_ATTR_RO macro and setting
> b_frame_index in __uvcg_fill_strm(). Would that be OK with you ? Or is
there a
> reason why the approach taken in your patch would be better ?
>
I've compared Paul's implementation to mine, and as far as I can tell,
they are functionally equivalent except for two points:
1) I specifically opted against using a generic UVCG_FRAME_ATTR_RO
macro, because the index has no well defined value until they are all
set at once, as such reading the attribute beforehand should return
-EBUSY before that point (instead of 1 for all indexes, which would be
the case now). All other attributes can be read immediately after
creation. Because my approach sets the frame indexes when the parent
format is linked, I check the target_fmt->linked flag; For Paul's
approach we would have to check whether __uvcg_fill_strm() has already
been called. Considering, that the format indices are set in the same
fashion, we should probably do the same for bFormatIndex.
2) My approach creates the bFrameIndexes as soon as a format has been
finalized and linked. Depending on how an application sets up the
gadget, this might make it easier to take note of the created indices at
the earliest possible time instead of rescanning everything at the end.
I do not think however this is a significant enough advantage to warrant
taking a different approach compared to the way format indices are
already being set.
Cheers,
Joël Pepper
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: dwc3: pci: Add GPIO lookup table on platforms without ACPI GPIO resources
Hi,
On 07-06-18 15:35, Hans de Goede wrote:
Hi,
On 07-06-18 15:28, Andy Shevchenko wrote:
On Thu, Jun 7, 2018 at 1:38 PM, Hans de Goede wrote:
Bay Trail / BYT SoCs do not have a builtin device-mode phy, instead
they require an external ULPI phy for device-mode.
Only some BYT devices have an external phy, but even on those devices
device-mode is not working because the dwc3 does not see the phy.
The problem is that the ACPI fwnode for the dwc3 does not contain the
expected GPIO resources for the GPIOs connected to the chip-select and
reset pins of the phy.
I've found the workaround which some Android x86 kernels use for this:
https://github.com/BORETS24/Kernel-for-Asus-Zenfone-2/blob/master/arch/x86/platform/intel-mid/device_libs/pci/platform_usb_otg.c
Which boils down to hardcoding the GPIOs for these devices.
This commit adds a gpiod_lookup_table adding the mappings from Android,
and installs this table on BYT system with their BIOS vendor DMI string
set to "INSYDE Corp.". This seems to indicate that a (mostly) unmodified
version of the reference design BIOS is used. 3 out of the 20 BYT tablets
which I have for testing have an external ULPI phy and all 3 models use
this vendor string.
+ vendor = dmi_get_system_info(DMI_BIOS_VENDOR);
+ if (vendor && strcmp(vendor, "INSYDE Corp.") == 0) {
+ gpiod_add_lookup_table(&platform_bytcr_gpios);
+ dwc->gpio_mapping_added = true;
+ }
I understand that my proposal might sound a bit overkill, though, I
would rather go with normal dmi tables and call back there.
I was actually thinking about maybe going the other direction and
dropping the DMI check all together if it turns out to be too
narrow. If you look at:
https://github.com/BORETS24/Kernel-for-Asus-Zenfone-2/blob/master/arch/x86/platform/intel-mid/device_libs/pci/platform_usb_otg.c
Then all models that code knows except for the 1st gen
development board (Bay Lake CRB/RVP FAB 1) use these gpios.
And *all* FFRDs (Form Factor Reference Designs) use these pins.
Note that the gpiolib code used the lookup table as a fallback,
so if there are proper ACPI GPIO resources in the resource table
those will be used.
So having a hardcoded fallback to the GPIO pins which all
FFRDs use seems reasonable.
And I've just hit my first tablet during testing which needs the GPIO
mapping and has a different BIOS vendor string.
I really don't want to play a game of whack-a-mole with adding more
and more DMI matches here.
So given that as mentioned above all boards seem to use the same
GPIOs and that this is only a fallback for when the GPIOs are
not listed in ACPI, I'm going to submit a v3 of this patch-set
which adds the mapping unconditionally.
Note that most BYT devices have the DWC3 controller disabled in the
BIOS, so this code will only get executed on the few devices which
enable it (because they actually have the external ULPI phy).
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
[PATCH v3 1/3] usb: dwc3: pci: Add GPIO lookup table on platforms without ACPI GPIO resources
Bay Trail / BYT SoCs do not have a builtin device-mode phy, instead
they require an external ULPI phy for device-mode.
Only some BYT devices have an external phy, but even on those devices
device-mode is not working because the dwc3 does not see the phy.
The problem is that the ACPI fwnode for the dwc3 does not contain the
expected GPIO resources for the GPIOs connected to the chip-select and
reset pins of the phy.
I've found the workaround which some Android x86 kernels use for this:
https://github.com/BORETS24/Kernel-for-Asus-Zenfone-2/blob/master/arch/x86/platform/intel-mid/device_libs/pci/platform_usb_otg.c
Which boils down to hardcoding the GPIOs for these devices.
The good news it that all boards (*) use the same GPIOs.
This commit fixes the ULPI phy not woring by adding a gpiod_lookup_table
call which adds a hardcoded mapping for BYT devices. Note that the mapping
added by gpiod_add_lookup_table is a fallback mapping, so boards which
properly provide GPIO resources in the ACPI firmware-node resources
will not use this.
*) Except for the first revision of the evalulation-kit, which normal users
don't have
Signed-off-by: Hans de Goede
---
Changes in v3:
-Add the mapping with gpiod_add_lookup_table() unconditionally on BYT
devices, as they are only used after checking for GPIO resources in ACPI
---
drivers/usb/dwc3/dwc3-pci.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index c961a94d136b..c58f87b01ac7 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -66,6 +67,15 @@ static const struct acpi_gpio_mapping acpi_dwc3_byt_gpios[]
= {
{ },
};
+static struct gpiod_lookup_table platform_bytcr_gpios = {
+ .dev_id = ":00:16.0",
+ .table = {
+ GPIO_LOOKUP("INT33FC:00", 54, "reset", GPIO_ACTIVE_HIGH),
+ GPIO_LOOKUP("INT33FC:02", 14, "cs", GPIO_ACTIVE_HIGH),
+ {}
+ },
+};
+
static int dwc3_pci_quirks(struct dwc3_pci *dwc)
{
struct platform_device *dwc3 = dwc->dwc3;
@@ -126,6 +136,13 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
if (ret)
dev_dbg(&pdev->dev, "failed to add mapping
table\n");
+ /*
+* A lot of BYT devices lack ACPI resource entries for
+* the GPIOs, add a fallback mapping to the reference
+* design GPIOs which all boards seem to use.
+*/
+ gpiod_add_lookup_table(&platform_bytcr_gpios);
+
/*
* These GPIOs will turn on the USB2 PHY. Note that we
have to
* put the gpio descriptors again here because the phy
driver
@@ -256,6 +273,7 @@ static void dwc3_pci_remove(struct pci_dev *pci)
{
struct dwc3_pci *dwc = pci_get_drvdata(pci);
+ gpiod_remove_lookup_table(&platform_bytcr_gpios);
#ifdef CONFIG_PM
cancel_work_sync(&dwc->wakeup_work);
#endif
--
2.17.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] usb: dwc3: pci: Use devm functions to get the phy GPIOs
Even though we only use them once, it is better to not put/release
the GPIOs immediately after use, so that others cannot claim them.
Use devm functions to get the phy GPIOs, so that they will be
automatically released when were unbound from the device and
remove the gpio_put calls.
Signed-off-by: Hans de Goede
---
drivers/usb/dwc3/dwc3-pci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 046f7f55789f..bd4d010e 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -179,20 +179,20 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
* put the gpio descriptors again here because the phy
driver
* might want to grab them, too.
*/
- gpio = gpiod_get_optional(&pdev->dev, "cs",
GPIOD_OUT_LOW);
+ gpio = devm_gpiod_get_optional(&pdev->dev, "cs",
+ GPIOD_OUT_LOW);
if (IS_ERR(gpio))
return PTR_ERR(gpio);
gpiod_set_value_cansleep(gpio, 1);
- gpiod_put(gpio);
- gpio = gpiod_get_optional(&pdev->dev, "reset",
GPIOD_OUT_LOW);
+ gpio = devm_gpiod_get_optional(&pdev->dev, "reset",
+ GPIOD_OUT_LOW);
if (IS_ERR(gpio))
return PTR_ERR(gpio);
if (gpio) {
gpiod_set_value_cansleep(gpio, 1);
- gpiod_put(gpio);
usleep_range(1, 11000);
}
}
--
2.17.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] usb: dwc3: pci: Enable ULPI Refclk on platforms where the firmware does not
On some Bay Trail (BYT) systems the firmware does not enable the
ULPI Refclk.
This commit adds a helper which checks and if necessary enabled the Refclk
and calls this helper for BYT machines.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Use pcim_iomap instead of parsing resources ourselves
-Add a comment about the msleep(100) call
---
drivers/usb/dwc3/dwc3-pci.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index c58f87b01ac7..046f7f55789f 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -41,6 +41,10 @@
#define PCI_INTEL_BXT_STATE_D0 0
#define PCI_INTEL_BXT_STATE_D3 3
+#define GP_RWBAR 1
+#define GP_RWREG1 0xa0
+#define GP_RWREG1_ULPI_REFCLK_DISABLE (1 << 17)
+
/**
* struct dwc3_pci - Driver private structure
* @dwc3: child dwc3 platform_device
@@ -76,6 +80,28 @@ static struct gpiod_lookup_table platform_bytcr_gpios = {
},
};
+static int dwc3_byt_enable_ulpi_refclock(struct pci_dev *pci)
+{
+ void __iomem*reg;
+ u32 value;
+
+ reg = pcim_iomap(pci, GP_RWBAR, 0);
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
+
+ value = readl(reg + GP_RWREG1);
+ if (!(value & GP_RWREG1_ULPI_REFCLK_DISABLE))
+ goto unmap; /* ULPI refclk already enabled */
+
+ value &= ~GP_RWREG1_ULPI_REFCLK_DISABLE;
+ writel(value, reg + GP_RWREG1);
+ /* This comes from the Intel Android x86 tree w/o any explanation */
+ msleep(100);
+unmap:
+ pcim_iounmap(pci, reg);
+ return 0;
+}
+
static int dwc3_pci_quirks(struct dwc3_pci *dwc)
{
struct platform_device *dwc3 = dwc->dwc3;
@@ -131,6 +157,11 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
if (pdev->device == PCI_DEVICE_ID_INTEL_BYT) {
struct gpio_desc *gpio;
+ /* On BYT the FW does not always enable the refclock */
+ ret = dwc3_byt_enable_ulpi_refclock(pdev);
+ if (ret)
+ return ret;
+
ret = devm_acpi_dev_add_driver_gpios(&pdev->dev,
acpi_dwc3_byt_gpios);
if (ret)
--
2.17.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] storage: Widen bcdDevice range for SanDisk SDDR-31 quirk
When I re-sent the patch with tabs I accidentally left the new maximum bcdDevice at 0x00ff. Sorry! Hopefully this is finally OK. The SanDisk SDDR-31 needs the US_FL_FIX_CAPACITY quirk. Previously that was only applied for bcdDevice 0x0009, but later firmware which reports bcdDevice 0x0022 needs it too. Signed-off-by: Mark Knibbs --- diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h index 747d3a9..dfcceaf 100644 --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -1044,7 +1044,7 @@ UNUSUAL_DEV( 0x0781, 0x0001, 0x0200, 0x0200, USB_SC_SCSI, USB_PR_CB, NULL, US_FL_SINGLE_LUN ), -UNUSUAL_DEV( 0x0781, 0x0002, 0x0009, 0x0009, +UNUSUAL_DEV( 0x0781, 0x0002, 0x, 0x0022, "SanDisk Corporation", "ImageMate CompactFlash USB", USB_SC_DEVICE, USB_PR_DEVICE, NULL, -- 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: Can Only Enable 2 Classes Using Gadget ConfigFS
>
> The attached script works only when 2 of the 3 given classes are enabled. The
> failure is that UDC is not writeable. Is there a limit I am reaching? I did
> not think I
> would get to 32 endpoints, so is there a limitation due to my device's
> construction?
>
> I can not find any good troubleshooting information.
>
> Thanks in advance,
> R0b0t1
>
I tried the similar, it works for one mass_storage and two ACMs, see below.
Since you have failed for last step, please debug your controller
driver's .udc_start function, and see what's wrong.
mkdir functions/mass_storage.0
ln -s functions/mass_storage.0 configs/c.1
mkdir functions/acm.0
ln -s functions/acm.0 configs/c.1
mkdir functions/acm.1
ln -s functions/acm.1 configs/c.1
Peter
>
> ---
>
>
> #!/bin/bash
> set -euo pipefail
>
> # General configuration:
> GADGET_NAME="testgadget"
> LANGUAGE=0x409
> MANUFACTURER="Sidney Spry"
> PRODUCT="Test Gadget"
>
> # Function configuration:
> HOST_ADDRESS="1a:55:89:a2:69:42"
> DEV_ADDRESS="1a:55:89:a2:69:41"
>
>
> if [ "$EUID" -ne 0 ]; then
> echo "This script must run as root."
> exit 1
> fi
>
>
> echo "Loading libcomposite..."
> CONFIGFS="/sys/kernel/config/usb_gadget"
> GADGET="$CONFIGFS/$GADGET_NAME"
> modprobe libcomposite
>
> while [ ! -d $CONFIGFS ]; do
> sleep 0.01
> done
>
>
> echo "Cleaning existing gadget..."
> find $GADGET/configs/*/* -maxdepth 0 -type l -exec rm {} \; || true find
> $GADGET/configs/*/strings/* -maxdepth 0 -type d -exec rmdir {} \; || true find
> $GADGET/os_desc/* -maxdepth 0 -type l -exec rm {} \; || true find
> $GADGET/functions/* -maxdepth 0 -type d -exec rmdir {} \; || true find
> $GADGET/strings/* -maxdepth 0 -type d -exec rmdir {} \; || true find
> $GADGET/configs/* -maxdepth 0 -type d -exec rmdir {} \; || true rmdir $GADGET
> ||
> true
>
> #find "$GADGET/configs" -maxdepth 2 -type l -exec "rm" {} \; #find
> "$GADGET"/configs/*/strings/* -maxdepth 0 -type d -exec "rmdir" {} \; #find
> "$GADGET"/os_desc/* -maxdepth 0 -type l -exec "rm" {} \; #find
> "$GADGET"/configs/functions/* -maxdepth 0 -type d -exec "rmdir" {} \; #find
> "$GADGET"/configs/* -maxdepth 0 -type d -exec "rmdir" {} \; #rmdir "$GADGET"
>
> echo "Creating gadget..."
> mkdir "$GADGET"
> cd "$GADGET"
>
> echo "Configuring device identifiers..."
> echo 0x1d6b > idVendor # Linux Foundation echo 0x0104 > idProduct #
> Multifunction Composite Gadget echo 0x0001 > bcdDevice # v0.1.0
> echo 0x0200 > bcdUSB# USB 2.0
> mkdir "strings/$LANGUAGE"
> echo "$MANUFACTURER" > "strings/$LANGUAGE/manufacturer"
> echo "$PRODUCT" > "strings/$LANGUAGE/product"
>
> echo "Configuring composite device..."
> echo 0xEF > bDeviceClass
> echo 0x02 > bDeviceSubClass
> echo 0x01 > bDeviceProtocol
>
> echo "Configuring OS-specific descriptors..."
> echo 1 > os_desc/use
> echo 0xcd> os_desc/b_vendor_code
> echo MSFT100 > os_desc/qw_sign
>
> echo "Creating Ethernet endpoint (CDC NCM) (1/1)..."
> mkdir "functions/ncm.usb0"
> #echo "$HOST_ADDRESS" > "functions/ncm.usb0/host_addr"
> #echo "$DEV_ADDRESS" > "functions/ncm.usb0/dev_addr"
>
> echo "Creating serial endpoint (1/2)..."
> mkdir "functions/acm.usb0"
>
> echo "Creating serial endpoint (2/2)..."
> mkdir "functions/acm.usb1"
>
> echo "Creating configuration..."
> mkdir "configs/c.1"
> echo 500 > "configs/c.1/MaxPower"
> mkdir "configs/c.1/strings/$LANGUAGE"
> echo "Config 1" > "configs/c.1/strings/$LANGUAGE/configuration"
> ln -s "functions/ncm.usb0" "configs/c.1"
> ln -s "functions/acm.usb0" "configs/c.1"
> ln -s "functions/acm.usb1" "configs/c.1"
> ln -s "configs/c.1" "os_desc/c.1"
>
> echo "Attaching device..."
> udevadm settle
> ls "/sys/class/udc/" > UDC
>
> echo "Done."
> --
> 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
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.kernel.or
> g%2Fmajordomo-
> info.html&data=02%7C01%7Cpeter.chen%40nxp.com%7C36400e0fa6f74d302eee0
> 8d5cea2f8a6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63664212
> 1727615349&sdata=ul4axDZIvQBn8Qoy1A2hbXhQEm0sRWr%2BHTWToC%2B4P
> dc%3D&reserved=0
Re: [PATCH v2] arm64: dts: msm8996: Use dwc3-qcom glue driver for USB
Hi, > On 5/31/2018 4:17 PM, Manu Gautam wrote: >> >> Move from dwc3-of-simple to dwc3-qcom glue driver to >> support peripheral mode which requires qscratch wrapper >> programming on VBUS event. I would like to test usb otg as peripheral role, but that's not clear for me which patches are required on top of linux master branch or linaro qcom-lt integration branch, or a custom branch which integrate dt-binding phy or usb related patch. Can you point me the patches I need to apply, or a branch, to test peripheral feature ? Thanks, Julien -- *This email and any attachment thereto are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please be advised that disclosing, copying, distributing or taking any action in reliance on the contents of this email is strictly prohibited. In such case, please immediately advise the sender, and delete all copies and attachment from your system. This email shall not be construed and is not tantamount to an offer, an acceptance of offer, or an agreement by SoftBank Robotics Europe on any discussion or contractual document whatsoever. No employee or agent is authorized to represent or bind SoftBank Robotics Europe to third parties by email, or act on behalf of SoftBank Robotics Europe by email, without express written confirmation by SoftBank Robotics Europe’ duly authorized representatives. * *Ce message électronique et éventuelles pièces jointes sont confidentiels, et exclusivement destinés à la personne ou l'entité à qui ils sont adressés. Si vous n'êtes pas le destinataire visé, vous êtes prié de ne pas divulguer, copier, distribuer ou prendre toute décision sur la foi de ce message électronique. Merci d'en aviser immédiatement l'expéditeur et de supprimer toutes les copies et éventuelles pièces jointes de votre système. Ce message électronique n'équivaut pas à une offre, à une acceptation d’offre, ou à un accord de SoftBank Robotics Europe sur toute discussion ou document contractuel quel qu’il soit, et ne peut être interprété comme tel. Aucun employé ou agent de SoftBank Robotics Europe n'est autorisé à représenter ou à engager la société par email, ou à agir au nom et pour le compte de la société par email, sans qu’une confirmation écrite soit donnée par le représentant légal de SoftBank Robotics Europe ou par toute autre personne ayant reçu délégation de pouvoir appropriée. * ** -- 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
