[PATCH 1/1] xhci: clear root port wake on bits if controller isn't wake-up capable
When the xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some Intel
platform may get a spurious wakeup, even if PCI PME# is disabled.
http://marc.info/?l=linux-usbm=138194006009255w=2
Signed-off-by: Lu Baolu baolu...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 6231ce6..fb771bd 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -22,6 +22,7 @@
#include linux/slab.h
+#include linux/device.h
#include asm/unaligned.h
#include xhci.h
@@ -1139,7 +1140,9 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
* is enabled, so also enable remote wake here.
*/
- if (hcd-self.root_hub-do_remote_wakeup) {
+ if (hcd-self.root_hub-do_remote_wakeup
+device_may_wakeup(hcd-self.controller)) {
+
if (t1 PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 = ~PORT_WKCONN_E;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Dell Precision M3800] DisplayLink USB Graphics adapter not working
[1.] Dell Precision M3800] DisplayLink USB Graphics adapter not working [2.] Dell USB Docking Station D3000. dmesg says that DisplayLink was found and DisplayLink is visible via lsusb, but nothing happens on the monitor. [3.] [4.] Linux version 3.15.0-031500-generic (apw@gomeisa) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201406081435 SMP Sun Jun 8 18:36:00 UTC 2014 [5.] [6.] [7.] Description:Ubuntu 14.04 LTS Release:14.04 [7.1.] If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux dhcp-110.s1 3.15.0-031500-generic #201406081435 SMP Sun Jun 8 18:36:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Gnu C 4.8 Gnu make 3.81 binutils 2.24 util-linux 2.20.1 mount support module-init-tools 15 e2fsprogs 1.42.9 pcmciautils018 PPP2.4.5 Linux C Library2.19 Dynamic linker (ldd) 2.19 Procps 3.3.9 Net-tools 1.60 Kbd1.15.5 Sh-utils 8.21 wireless-tools 30 Modules Loaded btrfs raid6_pq xor ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c cpuid hidp acpi_call nvram pci_stub vboxpci vboxnetadp vboxnetflt vboxdrv i8k ctr ccm ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 hid_generic nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp bridge stp llc ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables snd_usb_audio cdc_ether snd_usbmidi_lib snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core smsc75xx videodev usbnet mii hid_multitouch btusb bnep rfcomm bluetooth 6lowpan_iphc binfmt_misc arc4 nls_iso8859_1 pn544_mei mei_phy pn544 hci nfc x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm snd_hda_intel crct10dif_pclmul dell_laptop snd_hda_controller dcdbas snd_hda_codec crc32_pclmul ghash_clmulni_intel snd_hwdep snd_pcm iwlmvm snd_seq_midi snd_seq_midi_event aesni_intel mac80211 snd_rawmidi aes_x86_64 lrw nouveau gf128mul glue_helper ablk_helper cryptd i915 snd_seq snd_seq_device ttm snd_timer microcode drm_kms_helper iwlwifi drm snd rtsx_pci_ms cfg80211 i2c_algo_bit soundcore serio_raw mei_me memstick lpc_ich mei dell_wmi sparse_keymap mxm_wmi int3403_thermal wmi video joydev mac_hid parport_pc ppdev lp parport usbhid hid rtsx_pci_sdmmc psmouse ahci libahci rtsx_pci [7.2.] processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4702HQ CPU @ 2.20GHz stepping: 3 microcode : 0x17 cpu MHz : 2200.000 cache size : 6144 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid bogomips: 4389.81 clflush size: 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4702HQ CPU @ 2.20GHz stepping: 3 microcode : 0x17 cpu MHz : 2200.000 cache size : 6144 KB physical id : 0 siblings: 8 core id : 1 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid bogomips: 4389.81 clflush size: 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model
Re: [PATCH RFC 5/7] usb: gadget: configfs: changes for gadget bus introducing
On Tue, Jun 10, 2014 at 02:00:13PM +0200, Andrzej Pietrasiewicz wrote: Hi Peter, Hi Andrzej, First, many thanks for commenting and testing it. The reason why I changed gadget-configfs: - The gadget-configfs will register itself (as usb_gadget_driver) when specific udc attaches to it, with gadget bus introducing, each device driver will be added to gadget bus for each usb_gadget_driver, and the name for device driver need to be unique. - The device-model bind/unbind will do probe/remove, it can cover the functionalities of gadget_cdev_desc_UDC_store/show. W dniu 10.06.2014 06:32, Peter Chen pisze: - Deciding configfs device_driver's name according to creating sequence, it is still RFC - Register gadget driver at gadgets_make - Delete gadget_cdev_desc_UDC_store and gadget_cdev_desc_UDC_show interface, we can use standard device-model bind/unbind entry to bind specific udc to gadgetfs driver after disable gadget_bus's drivers_autoprobe I don't like this solution. If udc driver is compiled in and drivers_autoprobe is not disabled, one cannot create gadget's directory in configfs because the gadget does not contain any configurations yet at the moment of the said directory's creation. That's true, the probe will run when the gadget folder is creating, but no configuration at that time. Just creating gadget's directory is only a beginning of composing a gadget. In other words, the gadget is under construction until the user decides they are done. Constructing (composing) a gadget involves creating directories and writing to files inside gadget's directory. By the very nature of this process the gadget's directory must be created first and by design the gadget for sure is not ready then. So why to attempt binding it at this moment? Of course one can first write 0 to drivers_autoprobe, but first this attribute is located somewhere totally different than the gadget's configfs directory and second we loose the autoprobe capability. Please also note, that the user can change their mind and delete a gadget currently under construction, then create some other gadget and so on - until the user is satisfied gadget's directories can come and go. And with your solution usb_gadget_probe_driver() is called every time a gadget's directory is created. This is more often than necessary - it should be called only for gadgets really intended for binding. What I would like is keeping a mechanism similar storing the UDC's name into UDC attribute in configfs. It now serves a double purpose: first, to say the gadget is ready and second, to bind it to a particular udc. I would keep the first while the second is handled by the gadget bus. And of course the attribute's name should be changed to reflect its purpose: enable or commit or something similar. Some considerations for me are I want to keep auto-binding and manual-binding at the same time, it seems Felipe only wants to have manual-binding, then, things will be easier. Now, three things for gadget-configfs need to be decided, I would like to have your suggestion: - The name of device driver for each usb_gadget_driver, it needs to be unique, and the gadget may have multiple functions, see test my case below, so we can't use function name. How about the device driver name is the same with user created gadget name /sys/kernel/config/usb_gadget/gadget name /sys/bus/usb_gadget/drivers/gadget driver name gadget name is the same with gadget driver name for above? - When to register device driver to gadget bus? How about I create a enable attribute like you suggest above, and the device driver will be registered or removed when the user echo 1 or 0 to enable? - How udc attach/detach to gadget driver? How about like other gadget drivers that is using /sys/bus/gadget_bus/usb_gadget_driver/bind and /sys/bus/gadget_bus/usb_gadget_driver/unbind By the way, when I do this: For your two failure test cases: I haven't meet error. My code base: the top of Greg's usb-next (4a95b1fce97756d0333f8232eb7ed6974e93b054) with my seven patches, and I build in my udc driver. Below are my test step: - For g_ether root@freescale ~$ modprobe g_ether using random self ethernet address using random host ethernet address usb0: HOST MAC 4e:53:22:6e:d9:f6 usb0: MAC 46:e1:6c:c1:97:59 using random self ethernet address using random host ethernet address g_ether gadget: Ethernet Gadget, version: Memorial Day 2008 g_ether gadget: g_ether ready root@freescale ~$ g_ether gadget: high-speed config #1: CDC Ethernet (ECM) - For gadgetfs root@freescale ~$ modprobe libcomposite root@freescale ~$ mount none /sys/kernel/config/ -t configfs root@freescale ~$ echo 0 /sys/bus/usb_gadget/drivers_autoprobe root@freescale ~$ /** the first gadget / root@freescale ~$ mkdir /sys/kernel/config/usb_gadget/g1 root@freescale ~$ cd /sys/kernel/config/usb_gadget/g1/ root@freescale /sys/kernel/config/usb_gadget/g1$ echo 0x15a2 idVendor
Re: [PATCH v3] leds: USB: HID: Add support for MSI GT683R led panels
On Wed, 11 Jun 2014, Janne Kanniainen wrote: This driver adds support for USB controlled led panels that exists in MSI GT683R laptop Changes in v2: - sorted headers to alphabetic order - using devm_kzalloc - using BIT(n) - using usb_control_msg instead of usb_submit_urb - removing unneeded code Changes in v3: - implemented as HID device - some cleanups and bug fixes Signed-off-by: Janne Kanniainen janne.kanniai...@gmail.com Thanks for the driver. Johan, as you did a very good job reviewing this before I managed to get to it, I'd be glad to put your Reviewed-by: to the commit before commiting it, if you are going to provide it. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware bug in Intel USB-2 hub?
On Mon, 2014-06-09 at 11:11 -0400, Alan Stern wrote: On Mon, 9 Jun 2014, Toralf Förster wrote: On 06/19/2013 09:03 PM, Alan Stern wrote: Sarah: correctly and one didn't. Regardless, it was surprising to see Toralf's report that an Intel hub doesn't work right. I don't have any machines with a comparable chipset, so I can't test one of those integrated hubs directly. Can somebody at Intel look into this? Alan Stern Just tried kernel 3.15. - issue does still exists https://bugzilla.kernel.org/show_bug.cgi?id=59011 Not surprising, since it is a bug in the hardware. Alan, I don't like this, but it might be enough to simply revert 0aa2832dd0d9d8609fd8f15139bc7572541a1215. I am afraid we have to deal with real hardware, not specs. 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
[PATCH 6/7] fsl/otg: Add host-gadget drv sync delay
Resolve synchronization issue between host and gadget drivers
upon role-reversal
Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
Reviewed-by: Li Yang-R58472 le...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
drivers/usb/phy/phy-fsl-usb.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 490588d..5736183 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -578,8 +578,17 @@ int fsl_otg_start_gadget(struct otg_fsm *fsm, int on)
dev = otg-gadget-dev.parent;
if (on) {
- if (dev-driver-resume)
+ /* Delay gadget resume to synchronize between host and gadget
+* drivers. Upon role-reversal host drv is shutdown by kernel
+* worker thread. By the time host drv shuts down, controller
+* gets programmed for gadget role. Shutting host drv after
+* this results in controller getting reset, and it stops
+* responding to otg events
+*/
+ if (dev-driver-resume) {
+ msleep(1000);
dev-driver-resume(dev);
+ }
} else {
if (dev-driver-suspend)
dev-driver-suspend(dev, otg_suspend_state);
--
1.8.3.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 3/7] fsl/otg: Modify otg_event to start host drv
Add mechanism to start host driver from inside fsl_otg_even
upon each id change interrupt
Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
drivers/usb/phy/phy-fsl-usb.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index e8fa8c3..3a0cd23 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -711,6 +711,10 @@ static void fsl_otg_event(struct work_struct *work)
fsl_otg_start_host(fsm, 0);
otg_drv_vbus(fsm, 0);
fsl_otg_start_gadget(fsm, 1);
+ } else {
+ fsl_otg_start_gadget(fsm, 0);
+ otg_drv_vbus(fsm, 1);
+ fsl_otg_start_host(fsm, 1);
}
}
--
1.8.3.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 1/7] fsl/otg: Add controller version based ULPI and UTMI phy
Add controller version based ULPI and UTMI phy initialization for
otg driver
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
drivers/usb/phy/phy-fsl-usb.c | 20
drivers/usb/phy/phy-fsl-usb.h | 7 +++
2 files changed, 27 insertions(+)
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 2b0f968..dcffeae 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -957,12 +957,32 @@ int usb_otg_start(struct platform_device *pdev)
temp = ~(PORTSC_PHY_TYPE_SEL | PORTSC_PTW);
switch (pdata-phy_mode) {
case FSL_USB2_PHY_ULPI:
+ if (pdata-controller_ver) {
+ /* controller version 1.6 or above */
+ setbits32(p_otg-dr_mem_map-control,
+ USB_CTRL_ULPI_PHY_CLK_SEL);
+ /*
+* Due to controller issue of PHY_CLK_VALID in ULPI
+* mode, we set USB_CTRL_USB_EN before checking
+* PHY_CLK_VALID, otherwise PHY_CLK_VALID doesn't work.
+*/
+ clrsetbits_be32(p_otg-dr_mem_map-control,
+USB_CTRL_UTMI_PHY_EN, USB_CTRL_IOENB);
+ }
temp |= PORTSC_PTS_ULPI;
break;
case FSL_USB2_PHY_UTMI_WIDE:
temp |= PORTSC_PTW_16BIT;
/* fall through */
case FSL_USB2_PHY_UTMI:
+ if (pdata-controller_ver) {
+ /* controller version 1.6 or above */
+ setbits32(p_otg-dr_mem_map-control,
+USB_CTRL_UTMI_PHY_EN);
+ /* Delay for UTMI PHY CLK to become stable - 10ms */
+ mdelay(FSL_UTMI_PHY_DLY);
+ }
+ setbits32(p_otg-dr_mem_map-control, USB_CTRL_UTMI_PHY_EN);
temp |= PORTSC_PTS_UTMI;
/* fall through */
default:
diff --git a/drivers/usb/phy/phy-fsl-usb.h b/drivers/usb/phy/phy-fsl-usb.h
index 5986c96..653a4e8 100644
--- a/drivers/usb/phy/phy-fsl-usb.h
+++ b/drivers/usb/phy/phy-fsl-usb.h
@@ -199,6 +199,13 @@
/* control Register Bit Masks */
#define USB_CTRL_IOENB(0x12)
#define USB_CTRL_ULPI_INT0EN (0x10)
+#define USB_CTRL_WU_INT_EN(0x11)
+#define USB_CTRL_LINE_STATE_FILTER__EN(0x13)
+#define USB_CTRL_KEEP_OTG_ON (0x14)
+#define USB_CTRL_OTG_PORT (0x15)
+#define USB_CTRL_PLL_RESET(0x18)
+#define USB_CTRL_UTMI_PHY_EN (0x19)
+#define USB_CTRL_ULPI_PHY_CLK_SEL (0x110)
/* BCSR5 */
#define BCSR5_INT_USB (0x02)
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] fsl/otg: Add support to add/remove usb host driver
Add workqueue to add/remove host driver (outside interrupt context)
upon each id change
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
drivers/usb/host/ehci-fsl.c | 97 +++
drivers/usb/host/ehci.h | 5 ++-
drivers/usb/phy/phy-fsl-usb.c | 7 +++-
include/linux/usb.h | 1 +
4 files changed, 90 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index cf2734b..b026e7e 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -33,6 +33,54 @@
#include ehci-fsl.h
+struct ehci_fsl {
+ struct ehci_hcd ehci;
+
+#ifdef CONFIG_PM
+ /* Saved USB PHY settings, need to restore after deep sleep. */
+ u32 usb_ctrl;
+#endif
+
+ /* store current hcd state for otg;
+* have_hcd is true when host drv al already part of otg framework,
+* otherwise false;
+* hcd_add is true when otg framework wants to add host
+* drv as part of otg;flase when it wants to remove it
+*/
+ unsigned have_hcd:1;
+ unsigned hcd_add:1;
+};
+
+static struct ehci_fsl *hcd_to_ehci_fsl(struct usb_hcd *hcd)
+{
+ struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+
+ return container_of(ehci, struct ehci_fsl, ehci);
+}
+
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
+static void do_change_hcd(struct work_struct *work)
+{
+ struct ehci_hcd *ehci = container_of(work, struct ehci_hcd,
+ change_hcd_work);
+ struct usb_hcd *hcd = ehci_to_hcd(ehci);
+ struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
+ void __iomem *non_ehci = hcd-regs;
+ int retval;
+
+ if (ehci_fsl-hcd_add !ehci_fsl-have_hcd) {
+ writel(USBMODE_CM_HOST, non_ehci + FSL_SOC_USB_USBMODE);
+ /* host, gadget and otg share same int line */
+ retval = usb_add_hcd(hcd, hcd-irq, IRQF_SHARED);
+ if (retval == 0)
+ ehci_fsl-have_hcd = 1;
+ } else if (!ehci_fsl-hcd_add ehci_fsl-have_hcd) {
+ usb_remove_hcd(hcd);
+ ehci_fsl-have_hcd = 0;
+ }
+}
+#endif
+
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
@@ -132,11 +180,14 @@ static int usb_hcd_fsl_probe(const struct hc_driver
*driver,
goto err2;
device_wakeup_enable(hcd-self.controller);
-#ifdef CONFIG_USB_OTG
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
if (pdata-operating_mode == FSL_USB2_DR_OTG) {
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
hcd-phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+ INIT_WORK(ehci-change_hcd_work, do_change_hcd);
+
dev_dbg(pdev-dev, hcd=0x%p ehci=0x%p, phy=0x%p\n,
hcd, ehci, hcd-phy);
@@ -382,15 +433,6 @@ static int ehci_fsl_setup(struct usb_hcd *hcd)
return retval;
}
-struct ehci_fsl {
- struct ehci_hcd ehci;
-
-#ifdef CONFIG_PM
- /* Saved USB PHY settings, need to restore after deep sleep. */
- u32 usb_ctrl;
-#endif
-};
-
#ifdef CONFIG_PM
#ifdef CONFIG_PPC_MPC512x
@@ -538,24 +580,31 @@ static inline int ehci_fsl_mpc512x_drv_resume(struct
device *dev)
}
#endif /* CONFIG_PPC_MPC512x */
-static struct ehci_fsl *hcd_to_ehci_fsl(struct usb_hcd *hcd)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-
- return container_of(ehci, struct ehci_fsl, ehci);
-}
-
static int ehci_fsl_drv_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
void __iomem *non_ehci = hcd-regs;
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
+ struct usb_bus host = hcd-self;
+#endif
if (of_device_is_compatible(dev-parent-of_node,
fsl,mpc5121-usb2-dr)) {
return ehci_fsl_mpc512x_drv_suspend(dev);
}
+#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
+ if (host.is_otg) {
+ struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+
+ /* remove hcd */
+ ehci_fsl-hcd_add = 0;
+ schedule_work(ehci-change_hcd_work);
+ host.is_otg = 0;
+ return 0;
+ }
+#endif
ehci_prepare_ports_for_controller_suspend(hcd_to_ehci(hcd),
device_may_wakeup(dev));
if (!fsl_deep_sleep())
@@ -571,12 +620,26 @@ static int ehci_fsl_drv_resume(struct device *dev)
struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
void __iomem
[PATCH 4/7] fsl/otg: Combine host/gadget start/resume for ID change
Make call to fsl_otg_event for each id change even
Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
drivers/usb/phy/phy-fsl-usb.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 3a0cd23..490588d 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -767,6 +767,7 @@ irqreturn_t fsl_otg_isr(int irq, void *dev_id)
{
struct otg_fsm *fsm = ((struct fsl_otg *)dev_id)-fsm;
struct usb_otg *otg = ((struct fsl_otg *)dev_id)-phy.otg;
+ struct fsl_otg *otg_dev = dev_id;
u32 otg_int_src, otg_sc;
otg_sc = fsl_readl(usb_dr_regs-otgsc);
@@ -796,18 +797,8 @@ irqreturn_t fsl_otg_isr(int irq, void *dev_id)
otg-gadget-is_a_peripheral = !fsm-id;
VDBG(ID int (ID is %d)\n, fsm-id);
- if (fsm-id) { /* switch to gadget */
- schedule_delayed_work(
- ((struct fsl_otg *)dev_id)-otg_event,
- 100);
- } else {/* switch to host */
- cancel_delayed_work(
- ((struct fsl_otg *)dev_id)-
- otg_event);
- fsl_otg_start_gadget(fsm, 0);
- otg_drv_vbus(fsm, 1);
- fsl_otg_start_host(fsm, 1);
- }
+ schedule_delayed_work(otg_dev-otg_event, 100);
+
return IRQ_HANDLED;
}
}
--
1.8.3.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 5/7] fsl/otg: Remove host drv upon otg bring-up
Change have_hcd variable to remove/suspend host driver on
completion of otg initilization for otg auto detect
Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
Reviewed-by: Li Yang-R58472 le...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
drivers/usb/host/ehci-fsl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index b026e7e..121f0c8 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -183,6 +183,7 @@ static int usb_hcd_fsl_probe(const struct hc_driver *driver,
#if defined(CONFIG_FSL_USB2_OTG) || defined(CONFIG_FSL_USB2_OTG_MODULE)
if (pdata-operating_mode == FSL_USB2_DR_OTG) {
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+ struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
hcd-phy = usb_get_phy(USB_PHY_TYPE_USB2);
@@ -203,6 +204,11 @@ static int usb_hcd_fsl_probe(const struct hc_driver
*driver,
retval = -ENODEV;
goto err2;
}
+
+ ehci_fsl-have_hcd = 1;
+ } else {
+ dev_err(pdev-dev, wrong operating mode\n);
+ return -ENODEV;
}
#endif
return retval;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] leds: USB: HID: Add support for MSI GT683R led panels
On Wed, Jun 11, 2014 at 12:21:39AM +0300, Janne Kanniainen wrote:
This driver adds support for USB controlled led panels that exists in MSI
GT683R laptop
Can you break this line by 72 columns or so as well?
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
- removing unneeded code
Changes in v3:
- implemented as HID device
- some cleanups and bug fixes
Thanks for the update, Janne. It looks really good now.
Please put the changelog entries after the cut-off line below as it's
not really needed in the git logs.
You should also always run your patches through scripts/checkpatch.pl
before submitting. It currently reports 8 warnings of which you should
fix all but possible the ones about device id entries exceeding 80 chars
(which is usually considered acceptable).
A few more comments follow below.
Signed-off-by: Janne Kanniainen janne.kanniai...@gmail.com
---
drivers/hid/Kconfig | 6 ++
drivers/hid/Makefile| 1 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-gt683r.c| 186
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
6 files changed, 196 insertions(+)
create mode 100644 drivers/hid/hid-gt683r.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 7af9d0b..6ecc527 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -210,6 +210,12 @@ config DRAGONRISE_FF
Say Y here if you want to enable force feedback support for DragonRise
Inc.
game controllers.
+config HID_GT683R
+ tristate LED support for the MSI GT683R
How about rephrasing this description as MSI GT683R LED support as this
should make entry easier to find in Kconfig.
As there appears to be more models that could use this driver (and uses
the same PID) perhaps you should use MSI GT68xR or similar depending
on what models there are. We now of at least GX680R (having the same
PID, at least).
There's no need to rename the driver and every function or variable
below though (i.e. a gt683r prefix is still perfectly fine).
+ depends on LEDS_CLASS USB_HID
+ ---help---
+ Say Y here if you want to enable support for the MSI GT683R LEDS
+
checkpatch.pl suggests adding descriptive paragraph here.
config HID_EMS_FF
tristate EMS Production Inc. force feedback support
depends on HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index fc712dd..111304e 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_HID_CHICONY) += hid-chicony.o
obj-$(CONFIG_HID_CP2112) += hid-cp2112.o
obj-$(CONFIG_HID_CYPRESS)+= hid-cypress.o
obj-$(CONFIG_HID_DRAGONRISE) += hid-dr.o
+obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
Keep the entries sorted?
obj-$(CONFIG_HID_EMS_FF) += hid-emsff.o
obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
obj-$(CONFIG_HID_ELO)+= hid-elo.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index da52279..ec88fdb 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1827,6 +1827,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_2) },
diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
new file mode 100644
index 000..4baaa36
--- /dev/null
+++ b/drivers/hid/hid-gt683r.c
@@ -0,0 +1,186 @@
+/*
+ * MSI GT683R led driver
+ *
+ * Copyright (c) 2014 Janne Kanniainen janne.kanniai...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/hid.h
+#include linux/kernel.h
+#include linux/leds.h
+#include linux/module.h
+
+#include hid-ids.h
+
+#define GT683R_LED_BACK BIT(0)
+#define GT683R_LED_SIDE
Re: [PATCH v3] leds: USB: HID: Add support for MSI GT683R led panels
On Wed, Jun 11, 2014 at 01:25:49PM +0200, Jiri Kosina wrote: On Wed, 11 Jun 2014, Janne Kanniainen wrote: This driver adds support for USB controlled led panels that exists in MSI GT683R laptop Changes in v2: - sorted headers to alphabetic order - using devm_kzalloc - using BIT(n) - using usb_control_msg instead of usb_submit_urb - removing unneeded code Changes in v3: - implemented as HID device - some cleanups and bug fixes Signed-off-by: Janne Kanniainen janne.kanniai...@gmail.com Thanks for the driver. Johan, as you did a very good job reviewing this before I managed to get to it, I'd be glad to put your Reviewed-by: to the commit before commiting it, if you are going to provide it. I had a few more comments to v3, but I'll make sure to reply with a Reviewed-by-tag before you apply. Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hardware bug in Intel USB-2 hub?
On Wed, 11 Jun 2014, Oliver Neukum wrote: On Mon, 2014-06-09 at 11:11 -0400, Alan Stern wrote: On Mon, 9 Jun 2014, Toralf Förster wrote: On 06/19/2013 09:03 PM, Alan Stern wrote: Sarah: correctly and one didn't. Regardless, it was surprising to see Toralf's report that an Intel hub doesn't work right. I don't have any machines with a comparable chipset, so I can't test one of those integrated hubs directly. Can somebody at Intel look into this? Alan Stern Just tried kernel 3.15. - issue does still exists https://bugzilla.kernel.org/show_bug.cgi?id=59011 Not surprising, since it is a bug in the hardware. Alan, I don't like this, but it might be enough to simply revert 0aa2832dd0d9d8609fd8f15139bc7572541a1215. I am afraid we have to deal with real hardware, not specs. And I'm afraid you're right. It's a shame, because part of the reason I wrote that patch (although it wasn't mentioned in the description) was to prevent a class of bugs involving races between suspend and resume. But those bugs were largely theoretical, and the no regreesions rule takes precedence. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] libusbg: Fix potential memory leak in usbg_init()
Memory allocated with asprintf() for variable path
could be not free() in some cases. Fix this issue by
doing some small refactoring.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
src/usbg.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/src/usbg.c b/src/usbg.c
index edb7fc3..d1fb0b2 100644
--- a/src/usbg.c
+++ b/src/usbg.c
@@ -1218,6 +1218,7 @@ int usbg_init(char *configfs_path, usbg_state **state)
int ret = USBG_SUCCESS;
DIR *dir;
char *path;
+ usbg_state *s;
ret = asprintf(path, %s/usb_gadget, configfs_path);
if (ret 0)
@@ -1227,21 +1228,33 @@ int usbg_init(char *configfs_path, usbg_state **state)
/* Check if directory exist */
dir = opendir(path);
- if (dir) {
- closedir(dir);
- *state = malloc(sizeof(usbg_state));
- ret = *state ? usbg_init_state(path, *state)
-: USBG_ERROR_NO_MEM;
- if (*state ret != USBG_SUCCESS) {
- ERRORNO(couldn't init gadget state\n);
- usbg_free_state(*state);
- }
- } else {
+ if (!dir) {
ERRORNO(couldn't init gadget state\n);
ret = usbg_translate_error(errno);
- free(path);
+ goto err;
+ }
+
+ closedir(dir);
+ s = malloc(sizeof(usbg_state));
+ if (!s) {
+ ret = USBG_ERROR_NO_MEM;
+ goto err;
}
+ ret = usbg_init_state(path, s);
+ if (ret != USBG_SUCCESS) {
+ ERRORNO(couldn't init gadget state\n);
+ usbg_free_state(s);
+ goto out;
+ }
+
+ *state = s;
+
+ return ret;
+
+err:
+ free(path);
+out:
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] libusbg: Add support for functionFS.
Recent kernel versions supports creation of functionFS based
functions using configFS, so this library also should support this.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
include/usbg/usbg.h | 14 ++
src/usbg.c | 22 +-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/include/usbg/usbg.h b/include/usbg/usbg.h
index cb1cdcb..5509cdb 100644
--- a/include/usbg/usbg.h
+++ b/include/usbg/usbg.h
@@ -41,6 +41,8 @@
#define USBG_MAX_STR_LENGTH 256
#define USBG_MAX_PATH_LENGTH PATH_MAX
#define USBG_MAX_NAME_LENGTH 40
+/* Dev name for ffs is a part of function name, we subtracs 4 char for ffs.
*/
+#define USBG_MAX_DEV_LENGTH (USBG_MAX_NAME_LENGTH - 4)
/**
* @brief Additional option for usbg_rm_* functions.
@@ -144,6 +146,7 @@ typedef enum
F_EEM,
F_RNDIS,
F_PHONET,
+ F_FFS
} usbg_function_type;
/**
@@ -174,6 +177,16 @@ typedef struct {
} usbg_f_phonet_attrs;
/**
+ * @typedef usbg_f_ffs_attrs
+ * @brief Attributes for function fs based functions
+ * @details This is read only and virtual attribute it is non present
+ * on config fs.
+ */
+typedef struct {
+ char dev_name[USBG_MAX_DEV_LENGTH];
+} usbg_f_ffs_attrs;
+
+/**
* @typedef attrs
* @brief Attributes for a given function type
*/
@@ -181,6 +194,7 @@ typedef union {
usbg_f_serial_attrs serial;
usbg_f_net_attrs net;
usbg_f_phonet_attrs phonet;
+ usbg_f_ffs_attrs ffs;
} usbg_function_attrs;
/* Error codes */
diff --git a/src/usbg.c b/src/usbg.c
index d1fb0b2..04fbe11 100644
--- a/src/usbg.c
+++ b/src/usbg.c
@@ -104,6 +104,7 @@ const char *function_names[] =
eem,
rndis,
phonet,
+ ffs,
};
#define ERROR(msg, ...) do {\
@@ -800,6 +801,12 @@ static int usbg_parse_function_attrs(usbg_function *f,
ret = usbg_read_string(f-path, f-name, ifname,
f_attrs-phonet.ifname);
break;
+ case F_FFS:
+ strncpy(f_attrs-ffs.dev_name, f-instance,
+ sizeof(f_attrs-ffs.dev_name) - 1);
+ f_attrs-ffs.dev_name[sizeof(f_attrs-ffs.dev_name) - 1] = '\0';
+ ret = 0;
+ break;
default:
ERROR(Unsupported function type\n);
ret = USBG_ERROR_NOT_SUPPORTED;
@@ -1903,9 +1910,20 @@ int usbg_create_function(usbg_gadget *g,
usbg_function_type type,
int ret = USBG_ERROR_INVALID_PARAM;
int n, free_space;
- if (!g || !f || !instance)
+ if (!g || !f)
return ret;
+ if (!instance) {
+ /* If someone creates ffs function and doesn't pass instance
name
+ this means that device name from attrs should be used */
+ if (type == F_FFS f_attrs) {
+ instance = f_attrs-ffs.dev_name;
+ f_attrs = NULL;
+ } else {
+ return ret;
+ }
+ }
+
func = usbg_get_function(g, type, instance);
if (func) {
ERROR(duplicate function name\n);
@@ -2335,6 +2353,8 @@ int usbg_set_function_attrs(usbg_function *f,
usbg_function_attrs *f_attrs)
case F_PHONET:
ret = usbg_write_string(f-path, f-name, ifname,
f_attrs-phonet.ifname);
break;
+ case F_FFS:
+ ret = USBG_ERROR_NOT_SUPPORTED;
default:
ERROR(Unsupported function type\n);
ret = USBG_ERROR_NOT_SUPPORTED;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] libusbg: Update show gadget example support ffs functions.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com --- examples/show-gadgets.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/examples/show-gadgets.c b/examples/show-gadgets.c index 1ae3860..672eac3 100644 --- a/examples/show-gadgets.c +++ b/examples/show-gadgets.c @@ -108,6 +108,9 @@ void show_function(usbg_function *f) case F_PHONET: fprintf(stdout, ifname\t\t%s\n, f_attrs.phonet.ifname); break; + case F_FFS: + fprintf(stdout, dev_name\t\t%s\n, f_attrs.ffs.dev_name); + break; default: fprintf(stdout, UNKNOWN\n); } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] libusbg: Add example to show how to create ffs functions.
Add example which demonstartes two ways of creating ffs
based usb functions.
How to set-up gadget using this example:
1) Run gadget-ffs
2) Mount both instances:
$ mount my_dev_name -t functionfs /path/to/mount/dir1
$ mount my_awesome_dev_name -t functionfs /path/to/mount/dir2
3) Run ffs daemons for both instances:
$ my-ffs-daemon /path/to/mount/dir1
$ my-ffs-daemon /path/to/mount/dir2
4) Enable your gadget:
$ echo my_udc_name /sys/kernel/config/usb_gadget/g1/UDC
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
examples/Makefile.am |3 +-
examples/gadget-ffs.c | 154 +
2 files changed, 156 insertions(+), 1 deletion(-)
create mode 100644 examples/gadget-ffs.c
diff --git a/examples/Makefile.am b/examples/Makefile.am
index 9fc235a..abafe3c 100644
--- a/examples/Makefile.am
+++ b/examples/Makefile.am
@@ -1,6 +1,7 @@
-bin_PROGRAMS = show-gadgets gadget-acm-ecm gadget-vid-pid-remove
+bin_PROGRAMS = show-gadgets gadget-acm-ecm gadget-vid-pid-remove gadget-ffs
gadget_acm_ecm_SOURCES = gadget-acm-ecm.c
show_gadgets_SOURCES = show-gadgets.c
gadget_vid_pid_remove_SOURCES = gadget-vid-pid-remove.c
+gadget_ffs_SOURCES = gadget-ffs.c
AM_CPPFLAGS=-I../include/
AM_LDFLAGS=-L../src/ -lusbg
diff --git a/examples/gadget-ffs.c b/examples/gadget-ffs.c
new file mode 100644
index 000..062780e
--- /dev/null
+++ b/examples/gadget-ffs.c
@@ -0,0 +1,154 @@
+/*
+ * Copyright (C) 2014 Samsung Electronics
+ *
+ * Krzysztof Opasiak k.opas...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/**
+ * @file gadget-ffs.c
+ * @example gadget-ffs.c
+ * This is an example of how to create gadget with FunctionFS based functions
+ * in two ways. After executing this program gadget will not be enabled
+ * because ffs instances should be mounted and both descriptors and strings
+ * should be written to ep0.
+ * For more details about FunctionFS please refer to FunctionFS documentation
+ * in linux kernel repository.
+ */
+
+#include errno.h
+#include stdio.h
+#include usbg/usbg.h
+
+#define VENDOR 0x1d6b
+#define PRODUCT 0x0104
+
+int main(void)
+{
+ usbg_state *s;
+ usbg_gadget *g;
+ usbg_config *c;
+ usbg_function *f_ffs1, *f_ffs2;
+ int ret = -EINVAL;
+ int usbg_ret;
+ usbg_function_attrs f_attrs = {
+ .ffs = {
+ .dev_name = my_awesome_dev_name,
+ },
+ };
+
+ usbg_gadget_attrs g_attrs = {
+ 0x0200, /* bcdUSB */
+ 0x00, /* Defined at interface level */
+ 0x00, /* subclass */
+ 0x00, /* device protocol */
+ 0x0040, /* Max allowed packet size */
+ VENDOR,
+ PRODUCT,
+ 0x0001, /* Verson of device */
+ };
+
+ usbg_gadget_strs g_strs = {
+ 0123456789, /* Serial number */
+ Foo Inc., /* Manufacturer */
+ Bar Gadget /* Product string */
+ };
+
+ usbg_config_strs c_strs = {
+ 2xFFS
+ };
+
+ usbg_ret = usbg_init(/sys/kernel/config, s);
+ if (usbg_ret != USBG_SUCCESS) {
+ fprintf(stderr, Error on USB gadget init\n);
+ fprintf(stderr, Error: %s : %s\n, usbg_error_name(usbg_ret),
+ usbg_strerror(usbg_ret));
+ goto out1;
+ }
+
+ usbg_ret = usbg_create_gadget(s, g1, g_attrs, g_strs, g);
+ if (usbg_ret != USBG_SUCCESS) {
+ fprintf(stderr, Error on create gadget\n);
+ fprintf(stderr, Error: %s : %s\n, usbg_error_name(usbg_ret),
+ usbg_strerror(usbg_ret));
+ goto out2;
+ }
+
+ usbg_ret = usbg_create_function(g, F_FFS, my_dev_name, NULL, f_ffs1);
+ if (usbg_ret != USBG_SUCCESS) {
+ fprintf(stderr, Error creating ffs1 function\n);
+ fprintf(stderr, Error: %s : %s\n, usbg_error_name(usbg_ret),
+ usbg_strerror(usbg_ret));
+ goto out2;
+ }
+
+ /* When NULL is passed as instance name, dev_name take from f_attrs
+ is used as instance name for this function */
+ usbg_ret = usbg_create_function(g, F_FFS, NULL, f_attrs, f_ffs2);
+ if (usbg_ret != USBG_SUCCESS) {
+ fprintf(stderr, Error creating ffs2
Re: [PATCH 1/1] xhci: clear root port wake on bits if controller isn't wake-up capable
On Wed, Jun 11, 2014 at 06:25:20AM +0800, Lu Baolu wrote: When the xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend, xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some Intel platform may get a spurious wakeup, even if PCI PME# is disabled. http://marc.info/?l=linux-usbm=138194006009255w=2 Signed-off-by: Lu Baolu baolu...@linux.intel.com --- drivers/usb/host/xhci-hub.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Should this also be a stable kernel patch? If so, how far back? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: host: uhci-grlib.c : use devm_ functions
On Tue, 10 Jun 2014, Himangi Saraogi wrote: The various devm_ functions allocate memory that is released when a driver detaches. This patch uses devm_ioremap_resource for data that is allocated in the probe function of a platform device and is only freed in the remove function. The corresponding free functions are removed and two labels are done away with. Also, linux/device.h is added to make sure the devm_*() routine declarations are unambiguously available. Signed-off-by: Himangi Saraogi himangi...@gmail.com Acked-by: Julia Lawall julia.law...@lip6.fr --- v2: fix error of devm_ioremap_resource and change label names. + hcd-regs = devm_ioremap_resource(op-dev, hcd); Obviously you haven't tried to compile this. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] leds: USB: HID: Add support for MSI GT683R led panels
On Wed, Jun 11, 2014 at 04:05:42PM +0200, Johan Hovold wrote:
On Wed, Jun 11, 2014 at 12:21:39AM +0300, Janne Kanniainen wrote:
+static const char gt683r_led_select_leds[GT683R_BUFFER_SIZE] = { 0x01,
0x02, 0x30, 0x00,
+0x00, 0x00,
0x00, 0x00 };
+static const char gt683r_led_select_type[GT683R_BUFFER_SIZE] = { 0x01,
0x02, 0x20, 0x00,
+0x01, 0x00,
0x00, 0x00 };
80 char limit.
Perhaps move these to gt683r_led_set, which is the only place where they
are used?
Or, as I hinted earlier, just allocate the 8-byte buffer using kzalloc
and only initialise the non-zero bytes directly. The first byte should
be the report id (0x01). I noticed that some hid-drivers use this fact
when sending the raw request (see below).
+
+static void gt683r_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct gt683r_led *led =
+ container_of(led_cdev, struct gt683r_led, led_dev);
+
+ led-brightness = brightness;
+
+ schedule_work(led-work);
+}
+
+static int gt683r_led_snd_msg(struct gt683r_led *led, char *msg)
+{
+ int ret;
+
+ ret = hid_hw_raw_request(led-hdev, 0x01, msg, GT683R_BUFFER_SIZE,
+ HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
That is, you could use msg[0] here instead of 0x01.
+ if (ret 0) {
+ hid_err(led-hdev,
+ failed to send set report request: %i\n, ret);
+ return ret;
+ }
+
+ return 0;
+}
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] usb: ehci-exynos: Make provision for vdd regulators
On Fri, 6 Jun 2014, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
EHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Certain peripherals? Don't you mean certain controllers?
Does this mean some controllers don't need to use the VDD regulators?
@@ -193,7 +196,31 @@ static int exynos_ehci_probe(struct platform_device
*pdev)
err = exynos_ehci_get_phy(pdev-dev, exynos_ehci);
if (err)
- goto fail_clk;
+ goto fail_regulator1;
+
+ exynos_ehci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (!IS_ERR(exynos_ehci-vdd33)) {
+ err = regulator_enable(exynos_ehci-vdd33);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to enable 3.3V Vdd supply\n);
+ goto fail_regulator1;
+ }
+ } else {
+ dev_warn(pdev-dev, Regulator 3.3V Vdd supply not found\n);
+ }
What if this is one of the controllers that don't need to use a VDD
regulator? Do you really want to print out a warning in that case?
Should you call devm_regulator_get_optional() instead?
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dell Precision M3800] DisplayLink USB Graphics adapter not working
On Wed, Jun 11, 2014 at 08:49:34AM +0200, Bernhard Cygan wrote: [1.] Dell Precision M3800] DisplayLink USB Graphics adapter not working What is the vendor/product id of this device? You can get that with a simple `lsusb` output. The newer Displaylink device does not work on Linux as we do not know the protocol involved in talking to it. Please contact Displaylink about this issue as we can't do much without that information :( thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] leds: USB: HID: Add support for MSI GT683R led panels
On Wed, Jun 11, 2014 at 04:05:42PM +0200, Johan Hovold wrote:
On Wed, Jun 11, 2014 at 12:21:39AM +0300, Janne Kanniainen wrote:
+static int gt683r_led_snd_msg(struct gt683r_led *led, char *msg)
+{
+ int ret;
+
+ ret = hid_hw_raw_request(led-hdev, 0x01, msg, GT683R_BUFFER_SIZE,
+ HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
+ if (ret 0) {
+ hid_err(led-hdev,
+ failed to send set report request: %i\n, ret);
And here's one more: You need to check if ret != GT683R_BUFFER_SIZE and
make sure to return an error (e.g. -EIO) even if ret = 0 in that case.
+ return ret;
+ }
+
+ return 0;
+}
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] usb: host: uhci-grlib.c : use devm_ functions
The various devm_ functions allocate memory that is released when a
driver detaches. This patch uses devm_ioremap_resource for data
that is allocated in the probe function of a platform device and
is only freed in the remove function. The corresponding free functions
are removed and two labels are done away with. Also, linux/device.h
is added to make sure the devm_*() routine declarations are
unambiguously available.
Signed-off-by: Himangi Saraogi himangi...@gmail.com
---
Not compile tested due to incompatible architecture.
v3: pass correct arguments to devm_ioremap_resource
drivers/usb/host/uhci-grlib.c | 31 +--
1 file changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/host/uhci-grlib.c b/drivers/usb/host/uhci-grlib.c
index ab25dc3..05f57ff 100644
--- a/drivers/usb/host/uhci-grlib.c
+++ b/drivers/usb/host/uhci-grlib.c
@@ -17,6 +17,7 @@
* (C) Copyright 2004-2007 Alan Stern, st...@rowland.harvard.edu
*/
+#include linux/device.h
#include linux/of_irq.h
#include linux/of_address.h
#include linux/of_platform.h
@@ -113,24 +114,17 @@ static int uhci_hcd_grlib_probe(struct platform_device
*op)
hcd-rsrc_start = res.start;
hcd-rsrc_len = resource_size(res);
- if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len, hcd_name)) {
- printk(KERN_ERR %s: request_mem_region failed\n, __FILE__);
- rv = -EBUSY;
- goto err_rmr;
- }
-
irq = irq_of_parse_and_map(dn, 0);
if (irq == NO_IRQ) {
printk(KERN_ERR %s: irq_of_parse_and_map failed\n, __FILE__);
rv = -EBUSY;
- goto err_irq;
+ goto err_usb;
}
- hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
- if (!hcd-regs) {
- printk(KERN_ERR %s: ioremap failed\n, __FILE__);
- rv = -ENOMEM;
- goto err_ioremap;
+ hcd-regs = devm_ioremap_resource(op-dev, res);
+ if (IS_ERR(hcd-regs)) {
+ rv = PTR_ERR(hcd-regs);
+ goto err_irq;
}
uhci = hcd_to_uhci(hcd);
@@ -139,18 +133,14 @@ static int uhci_hcd_grlib_probe(struct platform_device
*op)
rv = usb_add_hcd(hcd, irq, 0);
if (rv)
- goto err_uhci;
+ goto err_irq;
device_wakeup_enable(hcd-self.controller);
return 0;
-err_uhci:
- iounmap(hcd-regs);
-err_ioremap:
- irq_dispose_mapping(irq);
err_irq:
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
-err_rmr:
+ irq_dispose_mapping(irq);
+err_usb:
usb_put_hcd(hcd);
return rv;
@@ -164,10 +154,7 @@ static int uhci_hcd_grlib_remove(struct platform_device
*op)
usb_remove_hcd(hcd);
- iounmap(hcd-regs);
irq_dispose_mapping(hcd-irq);
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
-
usb_put_hcd(hcd);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] usb: host: uhci-grlib.c : use devm_ functions
On Thu, 12 Jun 2014, Himangi Saraogi wrote: The various devm_ functions allocate memory that is released when a driver detaches. This patch uses devm_ioremap_resource for data that is allocated in the probe function of a platform device and is only freed in the remove function. The corresponding free functions are removed and two labels are done away with. Also, linux/device.h is added to make sure the devm_*() routine declarations are unambiguously available. Signed-off-by: Himangi Saraogi himangi...@gmail.com --- Not compile tested due to incompatible architecture. v3: pass correct arguments to devm_ioremap_resource Acked-by: Alan Stern st...@rowland.harvard.edu What happened to the corresponding patch for uhci-platform.c? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: usb5303: make use of uninitialized err variable
On Mon, Jun 2, 2014 at 7:45 PM, Emil Goode emilgo...@gmail.com wrote:
The variable err is not initialized here, this patch uses it
to store an eventual error value from devm_clk_get().
Signed-off-by: Emil Goode emilgo...@gmail.com
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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: Disable bus's drivers_autoprobe before rootfs has mounted
On Wed, Jun 11, 2014 at 11:23:23AM +0800, Peter Chen wrote: On Tue, Jun 10, 2014 at 09:10:00PM -0700, Greg KH wrote: On Wed, Jun 11, 2014 at 10:14:40AM +0800, Peter Chen wrote: Hi Greg, Currently, we can't disable auto probe function during booting if both device and device driver register code are built in due to .drivers_autoprobe is a private value for bus core and this value can only be changed by sys entry. Then don't build them into the kernel :) It causes we can't implement feature that the user can choose manual binding and auto binding through module parameters. Wait, you just asked about building the stuff into the kernel, not a module. Yes, build the code into the kernel. Eg, the default binding is automatic, but the user can override it by module parameter. Do we do that for any other bus anywhere? I don't know. Let's take USB peripheral as an example, there is a device for udc, and a device driver for usb gadget driver, at default, we want the device to be bound to driver automatically, this is what we have done now. But if there are more than one udcs and gadget drivers (eg one B port for mass storage, another B port for usb ethernet), the user may want to have specific binding (eg, udc-0 - mass storage, udc-1 - usb ethernet), so the binding will be established after rootfs has mounted. (This feature is implementing) Then there better be a way to describe this on the kernel command line (i.e. module paramaters), right? Which is a total mess, why not just not bind anything in this case and let the user pick what they want? If the user is used to do nothing at rootfs for current or earlier kernel, Is it ok we change the driver's behaviour and a sys entry is mandatory for user? We can't break existing systems, so I don't understand the issue here. Just don't configure your kernel for a system you don't have / want, right? From what I read code, we can't implement above feature, but I may be wrong, if you have some solutions, give me some hints please. If there is no solution for above feature, do we agree with exporting .drivers_autoprobe for bus driver or something similar? I don't understand what you mean by this, care to show me with code? I mean the individual bus driver can't change bus-p-drivers_autoprobe? bus-p-drivers_autoprobe is handled at drivers/base/bus.c. If the individual bus driver can change bus-p-drivers_autoprobe, we can disable autoprobe (auto-binding) during booting. No, that's a core only thing. 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 v2] uhci-platform: use devm_ioremap resource
This patch replaces the memory allocation using request_mem_region and
the ioremap by a single call to managed interface devm_ioremap_reource.
The corresponding calls to release_mem_region and iounmap in the probe
and release functions are now unnecessary and are removed. Also a label
is done away with and linux/device.h is added to make sure the devm_*()
outine declarations are unambiguously available.
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
---
v2: pass correct arguments to devm_ioremap_resource
Not compile tested due to incompatible architecture.
drivers/usb/host/uhci-platform.c | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/uhci-platform.c b/drivers/usb/host/uhci-platform.c
index 01833ab..b987f1d 100644
--- a/drivers/usb/host/uhci-platform.c
+++ b/drivers/usb/host/uhci-platform.c
@@ -8,6 +8,7 @@
*/
#include linux/of.h
+#include linux/device.h
#include linux/platform_device.h
static int uhci_platform_init(struct usb_hcd *hcd)
@@ -88,33 +89,22 @@ static int uhci_hcd_platform_probe(struct platform_device
*pdev)
hcd-rsrc_start = res-start;
hcd-rsrc_len = resource_size(res);
- if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len, hcd_name)) {
- pr_err(%s: request_mem_region failed\n, __func__);
- ret = -EBUSY;
+ hcd-regs = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(hcd-regs)) {
+ ret = PTR_ERR(hcd-regs);
goto err_rmr;
}
-
- hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
- if (!hcd-regs) {
- pr_err(%s: ioremap failed\n, __func__);
- ret = -ENOMEM;
- goto err_irq;
- }
uhci = hcd_to_uhci(hcd);
uhci-regs = hcd-regs;
ret = usb_add_hcd(hcd, pdev-resource[1].start, IRQF_SHARED);
if (ret)
- goto err_uhci;
+ goto err_rmr;
device_wakeup_enable(hcd-self.controller);
return 0;
-err_uhci:
- iounmap(hcd-regs);
-err_irq:
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
err_rmr:
usb_put_hcd(hcd);
@@ -126,8 +116,6 @@ static int uhci_hcd_platform_remove(struct platform_device
*pdev)
struct usb_hcd *hcd = platform_get_drvdata(pdev);
usb_remove_hcd(hcd);
- iounmap(hcd-regs);
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
usb_put_hcd(hcd);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disable bus's drivers_autoprobe before rootfs has mounted
On Wed, 11 Jun 2014, Greg KH wrote: We can't break existing systems, so I don't understand the issue here. Just don't configure your kernel for a system you don't have / want, right? From what I read code, we can't implement above feature, but I may be wrong, if you have some solutions, give me some hints please. If there is no solution for above feature, do we agree with exporting .drivers_autoprobe for bus driver or something similar? I don't understand what you mean by this, care to show me with code? I mean the individual bus driver can't change bus-p-drivers_autoprobe? bus-p-drivers_autoprobe is handled at drivers/base/bus.c. If the individual bus driver can change bus-p-drivers_autoprobe, we can disable autoprobe (auto-binding) during booting. No, that's a core only thing. Peter, correct me if this is wrong. It sounds like you want to have a way for the user to control which gadget driver gets bound to which UDC driver when everything is compiled into the kernel, nothing is built as a separate module. Is that the basic idea? This shouldn't be a problem if you use configfs or libusbg. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] uhci-platform: use devm_ioremap resource
On Thu, 12 Jun 2014, Himangi Saraogi wrote:
This patch replaces the memory allocation using request_mem_region and
the ioremap by a single call to managed interface devm_ioremap_reource.
The corresponding calls to release_mem_region and iounmap in the probe
and release functions are now unnecessary and are removed. Also a label
is done away with and linux/device.h is added to make sure the devm_*()
outine declarations are unambiguously available.
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
---
v2: pass correct arguments to devm_ioremap_resource
Not compile tested due to incompatible architecture.
uhci-platform is compatible with all architectures. But you have to
add it to the .config file by hand.
drivers/usb/host/uhci-platform.c | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/uhci-platform.c
b/drivers/usb/host/uhci-platform.c
index 01833ab..b987f1d 100644
--- a/drivers/usb/host/uhci-platform.c
+++ b/drivers/usb/host/uhci-platform.c
@@ -8,6 +8,7 @@
*/
#include linux/of.h
+#include linux/device.h
#include linux/platform_device.h
static int uhci_platform_init(struct usb_hcd *hcd)
@@ -88,33 +89,22 @@ static int uhci_hcd_platform_probe(struct platform_device
*pdev)
hcd-rsrc_start = res-start;
hcd-rsrc_len = resource_size(res);
- if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len, hcd_name)) {
- pr_err(%s: request_mem_region failed\n, __func__);
- ret = -EBUSY;
+ hcd-regs = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(hcd-regs)) {
+ ret = PTR_ERR(hcd-regs);
goto err_rmr;
Again, you didn't adjust the statement label. The rmr in err_rmr
stands for request_mem_region, so it is clearly out of place in your
patch.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disable bus's drivers_autoprobe before rootfs has mounted
On Wed, Jun 11, 2014 at 11:29:57AM +0800, Peter Chen wrote: On Tue, Jun 10, 2014 at 11:35:07PM -0500, Felipe Balbi wrote: Hi, On Tue, Jun 10, 2014 at 09:10:00PM -0700, Greg KH wrote: Let's take USB peripheral as an example, there is a device for udc, and a device driver for usb gadget driver, at default, we want the device to be bound to driver automatically, this is what we have done now. But if there are more than one udcs and gadget drivers (eg one B port for mass storage, another B port for usb ethernet), the user may want to have specific binding (eg, udc-0 - mass storage, udc-1 - usb ethernet), so the binding will be established after rootfs has mounted. (This feature is implementing) Then there better be a way to describe this on the kernel command line (i.e. module paramaters), right? Which is a total mess, why not just not bind anything in this case and let the user pick what they want? you can also blacklist all gadget drivers and manually probe them or - get this - you can refrain from using gadget drivers and use libusbg to build the gadget drivers out of raw usb functions, then bind them to the UDC of your liking. I am just worried if we change the behaviour of using gadget driver, can it be accepted by user? If you think it can be accepted if we can have some docs, we can implement manually binding for gadget driver from now on. user shouldn't have to deal with direct module insertion/removal (unless he's a developer and actually *wants* to do that). Docs are already in tree. The entire configfs interface has been documented, it's based on those documents that Matt started writing libusbg. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] uhci-platform: use devm_ioremap resource
v2: pass correct arguments to devm_ioremap_resource Not compile tested due to incompatible architecture. uhci-platform is compatible with all architectures. But you have to add it to the .config file by hand. What should one do exactly? I added CONFIG_USB_UHCI_PLATFORM=y to the end of my .config file, but then running make just overwrites it: make drivers/usb/host/uhci-platform.o scripts/kconfig/conf --silentoldconfig Kconfig # # configuration written to .config # CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh CC drivers/usb/host/uhci-platform.o drivers/usb/host/uhci-platform.c:13:38: warning: ‘struct usb_hcd’ declared inside parameter list [enabled by default] static int uhci_platform_init(struct usb_hcd *hcd) ^ thanks, julia
Re: [PATCH v2] uhci-platform: use devm_ioremap resource
On Wed, 11 Jun 2014, Julia Lawall wrote: v2: pass correct arguments to devm_ioremap_resource Not compile tested due to incompatible architecture. uhci-platform is compatible with all architectures. But you have to add it to the .config file by hand. What should one do exactly? I added CONFIG_USB_UHCI_PLATFORM=y to the end of my .config file, but then running make just overwrites it: By golly, you're right... I didn't realize it would do that. I guess you have to edit the drivers/usb/host/Kconfig file, changing config USB_UHCI_PLATFORM bool default y if ARCH_VT8500 to config USB_UHCI_PLATFORM bool default y or something equivalent. make drivers/usb/host/uhci-platform.o scripts/kconfig/conf --silentoldconfig Kconfig # # configuration written to .config # CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh CC drivers/usb/host/uhci-platform.o drivers/usb/host/uhci-platform.c:13:38: warning: �struct usb_hcd� declared inside parameter list [enabled by default] static int uhci_platform_init(struct usb_hcd *hcd) Do make drivers/usb/host/uhci-hcd.o instead of make drivers/usb/host/uhci-platform.o Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] uhci-platform: use devm_ioremap resource
On Wed, 11 Jun 2014, Alan Stern wrote: On Wed, 11 Jun 2014, Julia Lawall wrote: v2: pass correct arguments to devm_ioremap_resource Not compile tested due to incompatible architecture. uhci-platform is compatible with all architectures. But you have to add it to the .config file by hand. What should one do exactly? I added CONFIG_USB_UHCI_PLATFORM=y to the end of my .config file, but then running make just overwrites it: By golly, you're right... I didn't realize it would do that. I guess you have to edit the drivers/usb/host/Kconfig file, changing config USB_UHCI_PLATFORM bool default y if ARCH_VT8500 to config USB_UHCI_PLATFORM bool default y or something equivalent. make drivers/usb/host/uhci-platform.o scripts/kconfig/conf --silentoldconfig Kconfig # # configuration written to .config # CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CALLscripts/checksyscalls.sh CC drivers/usb/host/uhci-platform.o drivers/usb/host/uhci-platform.c:13:38: warning: ?struct usb_hcd? declared inside parameter list [enabled by default] static int uhci_platform_init(struct usb_hcd *hcd) Do make drivers/usb/host/uhci-hcd.o instead of make drivers/usb/host/uhci-platform.o OK, thanks for the explanations. julia -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch net-next 3/5] ipv6: consider net.ipv6.conf.all sysctls when making decisions
From: Milos Vyletel milos.vyle...@gmail.com Date: Tue, 10 Jun 2014 13:49:35 -0400 On Tue, Jun 10, 2014 at 1:13 PM, Stephen Hemminger step...@networkplumber.org wrote: On Tue, 10 Jun 2014 12:19:11 -0400 Milos Vyletel milos.vyle...@gmail.com wrote: As it is right now net.ipv6.conf.all.* are mostly ignored and instead we're only making decisions based on interface specific settings. These settings are coppied from net.ipv6.conf.default and changing either all or default settings have no effect. Although this is the right idea conceptually, it risks creating unhappy users because it changes the semantics of the API. This will probably break somebody's configuration. You're right but in this case I feel we are moving in the right direction. While the behavior will change in some cases this change is only adding well known ipv4 behavior for ipv6 sysctls. In fact documentation briefly mentioned that net.ipv6.conf.all.* should change all the interface-specific settings but that was not the case until now. You can't just break things on people, no matter how much you think the current behavior is poorly designed, inconsistent with other areas of the networking, etc. None of those things matter if you have to break things on people to fix it. I'm not applying this series, sorry. -- 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 v4] leds: USB: HID: Add support for MSI GT683R led panels
This driver adds support for USB controlled led panels that exists in MSI
GT683R laptop
Signed-off-by: Janne Kanniainen janne.kanniai...@gmail.com
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
- removing unneeded code
Changes in v3:
- implemented as HID device
- some cleanups and bug fixes
Changes in v4:
- more cleanups
- support for selecting leds
- support for selecting status
drivers/hid/Kconfig | 11 ++
drivers/hid/Makefile| 1 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-gt683r.c| 320
drivers/hid/hid-ids.h | 2 +-
drivers/hid/usbhid/hid-quirks.c | 2 +-
6 files changed, 335 insertions(+), 2 deletions(-)
create mode 100644 drivers/hid/hid-gt683r.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 7af9d0b..d93e0ae 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -261,6 +261,17 @@ config HOLTEK_FF
Say Y here if you have a Holtek On Line Grip based game controller
and want to have force feedback support for it.
+config HID_GT683R
+ tristate MSI GT68xR LED support
+ depends on LEDS_CLASS USB_HID
+ ---help---
+ Say Y here if you want to enable support for the MSI GT68xR LEDS
+
+ This driver support following states normal, breathing and audio.
+ You can also select which leds you want to enable.
+ Currently the following devices are know to be supported:
+ - MSI GT683R
+
config HID_HUION
tristate Huion tablets
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index fc712dd..7129311 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_HID_EMS_FF) += hid-emsff.o
obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
obj-$(CONFIG_HID_ELO) += hid-elo.o
obj-$(CONFIG_HID_EZKEY)+= hid-ezkey.o
+obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-mouse.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index da52279..ec88fdb 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1827,6 +1827,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_2) },
diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
new file mode 100644
index 000..04e4cc2
--- /dev/null
+++ b/drivers/hid/hid-gt683r.c
@@ -0,0 +1,320 @@
+/*
+ * MSI GT683R led driver
+ *
+ * Copyright (c) 2014 Janne Kanniainen janne.kanniai...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/device.h
+#include linux/hid.h
+#include linux/kernel.h
+#include linux/leds.h
+#include linux/module.h
+
+#include hid-ids.h
+
+#define GT683R_LED_BACKBIT(0)
+#define GT683R_LED_SIDEBIT(1)
+#define GT683R_LED_FRONT BIT(2)
+
+#define GT683R_BUFFER_SIZE 8
+
+/*
+ * GT683R_LED_OFF: all LEDs are off
+ * GT683R_LED_AUDIO: the status of LEDs depends
+ * on sound level
+ * GT683R_LED_BREATHING: LEDs brightness varies
+ * at human breathing rate
+ * GT683R_LED_NORMAL: LEDs are on
+ */
+enum gt683r_led_state {
+ GT683R_LED_OFF = 0,
+ GT683R_LED_AUDIO = 2,
+ GT683R_LED_BREATHING = 3,
+ GT683R_LED_NORMAL = 5
+};
+
+struct gt683r_led {
+ struct hid_device *hdev;
+ struct led_classdev led_dev_back;
+ struct led_classdev led_dev_side;
+ struct led_classdev led_dev_front;
+ struct mutex lock;
+ struct mutex state_lock;
+ struct work_struct work;
+ enum
Re: [PATCH 1/1] xhci: clear root port wake on bits if controller isn't wake-up capable
On 06/11/2014 11:26 PM, Greg Kroah-Hartman wrote: On Wed, Jun 11, 2014 at 06:25:20AM +0800, Lu Baolu wrote: When the xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend, xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some Intel platform may get a spurious wakeup, even if PCI PME# is disabled. http://marc.info/?l=linux-usbm=138194006009255w=2 Signed-off-by: Lu Baolu baolu...@linux.intel.com --- drivers/usb/host/xhci-hub.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Should this also be a stable kernel patch? If so, how far back? Yes. This patch should be back-ported to kernels as old as 2.6.37, that contains the commit 9777e3ce907d4cb5a513902a87ecd03b52499569 USB: xHCI: bus power management implementation. Thanks, -baolu thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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
Proposal.
I have a proposal for you. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] usb: ehci-exynos: Make provision for vdd regulators
On Thursday, June 12, 2014 12:39 AM, Alan Stern wrote:
On Fri, 6 Jun 2014, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
EHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Certain peripherals? Don't you mean certain controllers?
Does this mean some controllers don't need to use the VDD regulators?
@@ -193,7 +196,31 @@ static int exynos_ehci_probe(struct platform_device
*pdev)
err = exynos_ehci_get_phy(pdev-dev, exynos_ehci);
if (err)
- goto fail_clk;
+ goto fail_regulator1;
+
+ exynos_ehci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (!IS_ERR(exynos_ehci-vdd33)) {
+ err = regulator_enable(exynos_ehci-vdd33);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to enable 3.3V Vdd supply\n);
+ goto fail_regulator1;
+ }
+ } else {
+ dev_warn(pdev-dev, Regulator 3.3V Vdd supply not found\n);
+ }
What if this is one of the controllers that don't need to use a VDD
regulator? Do you really want to print out a warning in that case?
Should you call devm_regulator_get_optional() instead?
I agree with Alan's suggestion. This warning message is not
proper, when USB controllers that don't need a VDD regulator
are used. The devm_regulator_get_optional() looks better.
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] usb: host: uhci-grlib.c : use devm_ functions
On 2014-06-11 20:38, Himangi Saraogi wrote:
The various devm_ functions allocate memory that is released when a
driver detaches. This patch uses devm_ioremap_resource for data
that is allocated in the probe function of a platform device and
is only freed in the remove function. The corresponding free functions
are removed and two labels are done away with. Also, linux/device.h
is added to make sure the devm_*() routine declarations are
unambiguously available.
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Looks and works fine now!
Acked-by: Andreas Larsson andr...@gaisler.com
Best regards,
Andreas Larsson
---
Not compile tested due to incompatible architecture.
v3: pass correct arguments to devm_ioremap_resource
drivers/usb/host/uhci-grlib.c | 31 +--
1 file changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/host/uhci-grlib.c b/drivers/usb/host/uhci-grlib.c
index ab25dc3..05f57ff 100644
--- a/drivers/usb/host/uhci-grlib.c
+++ b/drivers/usb/host/uhci-grlib.c
@@ -17,6 +17,7 @@
* (C) Copyright 2004-2007 Alan Stern, st...@rowland.harvard.edu
*/
+#include linux/device.h
#include linux/of_irq.h
#include linux/of_address.h
#include linux/of_platform.h
@@ -113,24 +114,17 @@ static int uhci_hcd_grlib_probe(struct platform_device
*op)
hcd-rsrc_start = res.start;
hcd-rsrc_len = resource_size(res);
- if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len, hcd_name)) {
- printk(KERN_ERR %s: request_mem_region failed\n, __FILE__);
- rv = -EBUSY;
- goto err_rmr;
- }
-
irq = irq_of_parse_and_map(dn, 0);
if (irq == NO_IRQ) {
printk(KERN_ERR %s: irq_of_parse_and_map failed\n, __FILE__);
rv = -EBUSY;
- goto err_irq;
+ goto err_usb;
}
- hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
- if (!hcd-regs) {
- printk(KERN_ERR %s: ioremap failed\n, __FILE__);
- rv = -ENOMEM;
- goto err_ioremap;
+ hcd-regs = devm_ioremap_resource(op-dev, res);
+ if (IS_ERR(hcd-regs)) {
+ rv = PTR_ERR(hcd-regs);
+ goto err_irq;
}
uhci = hcd_to_uhci(hcd);
@@ -139,18 +133,14 @@ static int uhci_hcd_grlib_probe(struct platform_device
*op)
rv = usb_add_hcd(hcd, irq, 0);
if (rv)
- goto err_uhci;
+ goto err_irq;
device_wakeup_enable(hcd-self.controller);
return 0;
-err_uhci:
- iounmap(hcd-regs);
-err_ioremap:
- irq_dispose_mapping(irq);
err_irq:
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
-err_rmr:
+ irq_dispose_mapping(irq);
+err_usb:
usb_put_hcd(hcd);
return rv;
@@ -164,10 +154,7 @@ static int uhci_hcd_grlib_remove(struct platform_device
*op)
usb_remove_hcd(hcd);
- iounmap(hcd-regs);
irq_dispose_mapping(hcd-irq);
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
-
usb_put_hcd(hcd);
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
