Re: [PATCH] net: usb: lan78xx: use new api ethtool_{get|set}_link_ksettings

[David Miller]

From: Philippe Reynes 
Date: Sun,  9 Oct 2016 12:07:04 +0200

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied.
--
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: usbip: vhci extension: modifications to vhci driver

[fx IWATA NOBUO]

Hello,

I will send a patch to clear this warning.

The current behavior is as following:
vdev_to_vhci() is inline of container_of().
A pointer (struct vhci_hcd *vhci) may be container_of() from NULL for a
while.
If it is container_of() from NULL, it will not be referenced because of
 NULL check of source pointer of the container_of().

Thank you,

n.iwata
//
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Tuesday, October 11, 2016 4:03 PM
> To: fx IWATA NOBUO
> Cc: linux-usb@vger.kernel.org
> Subject: re: usbip: vhci extension: modifications to vhci driver
> 
> Hello Nobuo Iwata,
> 
> This is a semi-automatic email about new static checker warnings.
> 
> The patch 0775a9cbc694: "usbip: vhci extension: modifications to vhci
> driver" from Jun 13, 2016, leads to the following Smatch complaint:
> 
> drivers/usb/usbip/vhci_hcd.c:466 vhci_tx_urb()
>warn: variable dereferenced before check 'vdev' (see line 463)
> 
> drivers/usb/usbip/vhci_hcd.c
>462struct vhci_priv *priv;
>463struct vhci_hcd *vhci = vdev_to_vhci(vdev);
> ^^ Patch adds a
> new dereference inside the vdev_to_vhci() function.
> 
>464unsigned long flags;
>465
>466if (!vdev) {
> ^
> Old code assumed "vdev" could be NULL.
> 
>467pr_err("could not get virtual device");
>468return;
> 
> regards,
> dan carpenter
--
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

Jack sensing in snd_usb_audio ?

[Bastien Nocera]

Hey,

I recently bought some cheap USB soundcards for a computer that doesn't
have any audio output other than through the HDMI output, and the
screen I'm attaching doesn't have an audio output.

So I'm looking to plug in 2 of those USB soundcards, and switch between
them depending on whether I'm using headphones, or want to use the
standalone speaker.

Obviously, it would be so much nicer if I didn't have to switch between
the outputs by hand, and ignored the "headphones" sound card when not
plugged in.

My questions are:
- does the USB audio driver support jack sensing?
- is this something standard that's just not implemented yet? In which
case, I'd be up for at least trying, given specs.
- or is it something that depends on the device, and in which case, how
would I find out?

Some details about the device itself below.

Cheers

/proc/asound/cards:
 4 [Device ]: USB-Audio - USB Audio Device
  GeneralPlus USB Audio Device at usb-:00:14.0-9, full 
speed

$ amixer -c 4
Simple mixer control 'Speaker',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 30
  Mono:
  Front Left: Playback 16 [53%] [-21.00dB] [on]
  Front Right: Playback 16 [53%] [-21.00dB] [on]
Simple mixer control 'Mic',0
  Capabilities: pvolume pvolume-joined cvolume cvolume-joined pswitch
pswitch-joined cswitch cswitch-joined
  Playback channels: Mono
  Capture channels: Mono
  Limits: Playback 0 - 14 Capture 0 - 30
  Mono: Playback 1 [7%] [-10.50dB] [off] Capture 26 [87%] [27.00dB]
[on]
Simple mixer control 'Auto Gain Control',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [off]
--
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

Fast Loans

[Global Financial Services]

Do you need a loan? If yes, email us for more information.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Hi!

I'm sorry, I'm not savvy enough to know what to do with this (I know 
basics on how to code and compile, but I'm no dev). Could someone 
guide me through it?

I gather this patch needs to be applied to some kernel module code 
which needs to be compiled and reloaded into my current kernel, 
right?

Sorry to let you down...

Cheers,
Pierre.

Le mardi 11 octobre 2016, 11:18:28 NZDT Alan Stern a écrit :
> On Sat, 8 Oct 2016, Lukas Wunner wrote:
> > The PCI core already calls pm_runtime_get_sync() before invoking 
the
> > ->probe hook of a driver (see local_pci_probe()).  Drivers need 
to
> > explicitly release a runtime ref to allow their device to 
suspend.
> > 
> > For xhci-pci, this seems to happen in usb_hcd_pci_probe():
> > if (pci_dev_run_wake(dev))
> > 
> > pm_runtime_put_noidle(>dev);
> > 
> > So you could either modify the if-condition if you want to 
change the
> > behaviour for XHCI devices only, or if you want to change it in 
general,
> > 
> > add something like this to pci_dev_run_wake():
> > /* PME capable in principle, but not from the intended sleep 
state */
> > if (dev->pme_support && !pci_pme_capable(dev, 
pci_target_state(dev)))
> > 
> > return false;
> > 
> > I've briefly looked over the callers of pci_dev_run_wake() and 
the above
> > seems safe but you should double-check them.
> 
> That seems like a good suggestion.  The patch is below; Pierre, 
can you
> test it?  This should remove the need to set the USB autosuspend 
module
> parameter to -1.
> 
> Alan Stern
> 
> 
> 
> Index: usb-4.x/drivers/pci/pci.c
> 
===
> --- usb-4.x.orig/drivers/pci/pci.c
> +++ usb-4.x/drivers/pci/pci.c
> @@ -2064,6 +2064,10 @@ bool pci_dev_run_wake(struct pci_dev *de
>   if (!dev->pme_support)
>   return false;
> 
> + /* PME-capable in principle, but not from the intended sleep 
state */
> + if (!pci_pme_capable(dev, pci_target_state(dev)))
> + return false;
> +
>   while (bus->parent) {
>   struct pci_dev *bridge = bus->self;
--
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] usb: gadget: dummy_hcd: clear struct gadget on removal

[Rob Herring]

The addition of CONFIG_DEBUG_TEST_DRIVER_REMOVE uncovered a bug in
dummy_hcd driver. The problem is the gadget's struct device is allocated
once in the initcall, so re-probing the device causes this warning:

[   13.516309] kobject (8f92f8b4): tried to init an initialized object, 
something is seriously wrong.
[   13.518358] CPU: 0 PID: 1 Comm: swapper Not tainted 4.8.0-rc4-3-gbea5b15 
#1
[   13.520014] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   13.522207]  8f92f8b4 8f92f8b4 80031d20 88bb56c9 80031d3c 88bb7dd3 898316d4 
8f92f8b4
[   13.524132]  8f92f868 899b8c6c 8f92f8ac 80031d4c 88d83cce 8f92f868 8f92f8ac 
80031d58
[   13.526087]  88d844bb 8f92f868 80031d84 88ef3c1d  89863eac  
8004f760
[   13.527980] Call Trace:
[   13.528540]  [<88bb56c9>] dump_stack+0x16/0x1d
[   13.529544]  [<88bb7dd3>] kobject_init+0x73/0x80
[   13.530602]  [<88d83cce>] device_initialize+0x1e/0xe0
[   13.531889]  [<88d844bb>] device_register+0xb/0x20
[   13.532997]  [<88ef3c1d>] usb_add_gadget_udc_release+0x8d/0x270
[   13.534333]  [<88ef3e9a>] usb_add_gadget_udc+0xa/0x10
[   13.535465]  [<88ef775e>] dummy_udc_probe+0x14e/0x1a0
[   13.536623]  [<88d89781>] platform_drv_probe+0x31/0x90
[   13.537830]  [<88d875aa>] ? driver_sysfs_add+0x6a/0x90
[   13.539014]  [<88d87e3a>] driver_probe_device+0x12a/0x490
[   13.540228]  [<88cbc39b>] ? acpi_driver_match_device+0x36/0x50
[   13.541658]  [<88d88307>] __device_attach_driver+0x77/0x110
[   13.542946]  [<8949712d>] ? klist_next+0x6d/0x10c
[   13.544053]  [<88d88290>] ? __driver_attach+0xf0/0xf0
[   13.545180]  [<88d864f7>] bus_for_each_drv+0x47/0x80
[   13.549626]  [<88d87b85>] __device_attach+0xb5/0x130
[   13.550493]  [<88d88290>] ? __driver_attach+0xf0/0xf0
[   13.551517]  [<88d883cd>] device_initial_probe+0xd/0x10
[   13.552485]  [<88d86787>] bus_probe_device+0x77/0x80
[   13.553298]  [<88d8417e>] device_add+0x34e/0x5a0
[   13.554025]  [<88bc4840>] ? kvasprintf_const+0x40/0x90
[   13.554860]  [<88bb7d1b>] ? kobject_set_name_vargs+0x6b/0x90
[   13.555770]  [<88d89e6c>] platform_device_add+0xfc/0x280
[   13.556640]  [<89ad0b84>] init+0x20b/0x2ec
[   13.557317]  [<89ad0979>] ? usb_udc_init+0x3f/0x3f
[   13.558154]  [<89a96c1d>] do_one_initcall+0x7c/0xfb
[   13.558947]  [<89a96d5e>] ? kernel_init_freeable+0xc2/0x15e
[   13.559851]  [<89a96d81>] kernel_init_freeable+0xe5/0x15e
[   13.560726]  [<894974fb>] kernel_init+0xb/0x100
[   13.561705]  [<888c727c>] ? schedule_tail+0xc/0x50
[   13.562786]  [<894a1942>] ret_from_kernel_thread+0xe/0x24
[   13.563993]  [<894974f0>] ? rest_init+0x110/0x110

Fix this by clearing struct gadget containing the struct device on
removal. This could also be fixed by disabling bind/unbind, but that is
perhaps a useful feature to simulate device attach/detach.

Reported-by: kernel test robot 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
Signed-off-by: Rob Herring 
---
 drivers/usb/gadget/udc/dummy_hcd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/gadget/udc/dummy_hcd.c 
b/drivers/usb/gadget/udc/dummy_hcd.c
index 77d07904f932..64f3d3cdcb91 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -1060,6 +1060,7 @@ static int dummy_udc_remove(struct platform_device *pdev)
 
device_remove_file(>gadget.dev, _attr_function);
usb_del_gadget_udc(>gadget);
+   memset(>gadget, 0, sizeof(dum->gadget));
return 0;
 }
 
-- 
2.10.0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hot-plug not working (ASUS TP301UA-C4028T)

[Alan Stern]

On Sat, 8 Oct 2016, Lukas Wunner wrote:

> The PCI core already calls pm_runtime_get_sync() before invoking the
> ->probe hook of a driver (see local_pci_probe()).  Drivers need to
> explicitly release a runtime ref to allow their device to suspend.
> For xhci-pci, this seems to happen in usb_hcd_pci_probe():
> 
>   if (pci_dev_run_wake(dev))
>   pm_runtime_put_noidle(>dev);
> 
> So you could either modify the if-condition if you want to change the
> behaviour for XHCI devices only, or if you want to change it in general,
> add something like this to pci_dev_run_wake():
> 
>   /* PME capable in principle, but not from the intended sleep state */
>   if (dev->pme_support && !pci_pme_capable(dev, pci_target_state(dev)))
>   return false;
> 
> I've briefly looked over the callers of pci_dev_run_wake() and the above
> seems safe but you should double-check them.

That seems like a good suggestion.  The patch is below; Pierre, can you 
test it?  This should remove the need to set the USB autosuspend module 
parameter to -1.

Alan Stern



Index: usb-4.x/drivers/pci/pci.c
===
--- usb-4.x.orig/drivers/pci/pci.c
+++ usb-4.x/drivers/pci/pci.c
@@ -2064,6 +2064,10 @@ bool pci_dev_run_wake(struct pci_dev *de
if (!dev->pme_support)
return false;
 
+   /* PME-capable in principle, but not from the intended sleep state */
+   if (!pci_pme_capable(dev, pci_target_state(dev)))
+   return false;
+
while (bus->parent) {
struct pci_dev *bridge = bus->self;
 

--
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: Unable to safely detach external HDD on USB 3.0

[Mathias Nyman]

On 09.10.2016 16:30, Marco Chiappero wrote:

Il 03/10/2016 07:58, Mathias Nyman ha scritto:

On 02.10.2016 13:23, Marco Chiappero wrote:

Hi all,

Sorry for bothering you but I would like to know whether there are updates on 
this or not.
This problem is affecting many people and has been identified, it would be a 
pity not to have a fix upstreamed.

Let me know if I can help somehow.



Right, there is a test patch in my tree, in the remount_fix_test branch,
based on 4.8-rc6

git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git remount_fix_test

I was about to go through the remote wakeup flags for this before I got pulled
into other things. If you can try it out and see if works for you it would help.


Hi Mathias,

Sorry for my "ping" email, since I saw no more emails I thought no progress has 
been made.

I managed to test your code today by plugging and unplugging the drive many 
times from both USB 2.0 and 3.0 ports, they work just the same now, without a 
issue.

Thank you so much for the fix. If there is still something I can do, just let 
me know.



Great, thanks for testing

-Mathias


--
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 v8 1/1] USB: serial: cp210x: Adding GPIO support for CP2105

[Martyn Welch]

This patch adds support for the GPIO found on the CP2105. Unlike the GPIO
provided by some of the other devices supported by the cp210x driver, the
GPIO on the CP2015 is muxed on pins otherwise used for serial control
lines. The GPIO have been configured in 2 separate banks as the choice to
configure the pins for GPIO is made separately for pins shared with each
of the 2 serial ports this device provides, though the choice is made for
all pins associated with that port in one go. The choice of whether to use
the pins for GPIO or serial is made by adding configuration to a one-time
programable PROM in the chip and can not be changed at runtime. The device
defaults to GPIO.

This device supports either push-pull or open-drain modes, it doesn't
provide an explicit input mode, though the state of the GPIO can be read
when used in open-drain mode. Like with pin use, the mode is configured in
the one-time programable PROM and can't be changed at runtime.

Signed-off-by: Martyn Welch 
---

V2: - Doesn't break build when gpiolib isn't selected.

V3: - Tracking GPIO state so pins no longer get their state changed should
  the pin be in open-drain mode and be pulled down externally whilst
  another pin is set.
- Reworked buffers and moved to byte accesses to remove the
  questionable buffer size logic and byte swapping.
- Added error reporting.
- Removed incorrect/pointless comments.
- Renamed tmp variable to make use clearer.

V4: - Fixed memory leak in cp210x_gpio_get error path.

V5: - Determining shared GPIO based on device type.
- Reordered vendor specific values by value.
- Use interface device for gpio messages.
- Remove unnecessary empty lines.
- Using kzalloc rather than kcalloc.
- Added locking to port_priv->output_state.
- Added dummy cp2105_shared_gpio_init for !CONFIG_GPIOLIB.
- Removed unnecessary masking on u8.
- Added support for use of GPIO pin as RS485 traffic indication or
  activity LEDs.
- Use correct dev for GPIO device.
- Set can_sleep.
- Roll in initial configuration state support.
- Print error message & continue if GPIO fails.
- Simplified ifdef'ing.

V6: - Remove unused define.
- Renamed cp210x_dev_private, cp210x_serial_private.
- Moved GPIO variables to cp210x_serial_private.
- Renamed PARTNUM defines.
- Switched to using bitops for GPIO mode bits.
- Moved vendor-specific defiles to end of defines.
- Added helpers for vendor requests.
- Using structs rather than byte arrays for sent and recieved values.
- Exposing total number of GPIOs and refusing requests for pins not
  configured as GPIO, removing gpio_map in process.
- Added checks for allocation failures.
- Using same label for both banks of GPIO.
- Moved GPIO into to attach function.

V7: - Using GPIO private data for GPIO bits.
- Adding limited .set_single_ended() and direction support.
- Simplifying attach() and removing release() as it's no longer required.

v8: - Re-fix for when gpiolib isn't selected.

 drivers/usb/serial/cp210x.c | 366 +++-
 1 file changed, 363 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 4d6a5c6..f996142 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -23,6 +23,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #define DRIVER_DESC "Silicon Labs CP210x RS232 serial adaptor driver"
 
@@ -44,6 +47,7 @@ static int cp210x_tiocmset(struct tty_struct *, unsigned int, 
unsigned int);
 static int cp210x_tiocmset_port(struct usb_serial_port *port,
unsigned int, unsigned int);
 static void cp210x_break_ctl(struct tty_struct *, int);
+static int cp210x_attach(struct usb_serial *);
 static int cp210x_port_probe(struct usb_serial_port *);
 static int cp210x_port_remove(struct usb_serial_port *);
 static void cp210x_dtr_rts(struct usb_serial_port *p, int on);
@@ -207,6 +211,15 @@ static const struct usb_device_id id_table[] = {
 
 MODULE_DEVICE_TABLE(usb, id_table);
 
+#ifdef CONFIG_GPIOLIB
+struct cp210x_gpio_private {
+   struct usb_serial   *serial;
+   struct gpio_chipgc;
+   u8  config;
+   u8  gpio_mode;
+};
+#endif
+
 struct cp210x_port_private {
__u8bInterfaceNumber;
boolhas_swapped_line_ctl;
@@ -228,6 +241,7 @@ static struct usb_serial_driver cp210x_device = {
.tx_empty   = cp210x_tx_empty,
.tiocmget   = cp210x_tiocmget,
.tiocmset   = cp210x_tiocmset,
+   .attach = cp210x_attach,
.port_probe = cp210x_port_probe,
.port_remove= cp210x_port_remove,
.dtr_rts= cp210x_dtr_rts
@@ -270,6 +284,7 @@ static struct 

Re: [RESEND PATCH v6, 4/5] usb: Add MediaTek USB3 DRD Driver

[Matthias Brugger]

On 10/11/2016 05:14 AM, Chunfeng Yun wrote:

On Mon, 2016-10-10 at 13:00 +0200, Matthias Brugger wrote:


On 09/21/2016 07:54 AM, Chunfeng Yun wrote:

This patch adds support for the MediaTek USB3 controller
integrated into MT8173. It can be configured as Dual-Role
Device (DRD), Peripheral Only and Host Only (xHCI) modes.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/Kconfig|2 +
 drivers/usb/Makefile   |1 +
 drivers/usb/mtu3/Kconfig   |   54 +++
 drivers/usb/mtu3/Makefile  |   19 +
 drivers/usb/mtu3/mtu3.h|  422 +
 drivers/usb/mtu3/mtu3_core.c   |  871 +++
 drivers/usb/mtu3/mtu3_dr.c |  379 
 drivers/usb/mtu3/mtu3_dr.h |  108 +
 drivers/usb/mtu3/mtu3_gadget.c |  731 +
 drivers/usb/mtu3/mtu3_gadget_ep0.c |  883 
 drivers/usb/mtu3/mtu3_host.c   |  294 
 drivers/usb/mtu3/mtu3_hw_regs.h|  473 +++
 drivers/usb/mtu3/mtu3_plat.c   |  490 
 drivers/usb/mtu3/mtu3_qmu.c|  599 
 drivers/usb/mtu3/mtu3_qmu.h|   43 ++
 15 files changed, 5369 insertions(+)
 create mode 100644 drivers/usb/mtu3/Kconfig
 create mode 100644 drivers/usb/mtu3/Makefile
 create mode 100644 drivers/usb/mtu3/mtu3.h
 create mode 100644 drivers/usb/mtu3/mtu3_core.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.h
 create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
 create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
 create mode 100644 drivers/usb/mtu3/mtu3_host.c
 create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
 create mode 100644 drivers/usb/mtu3/mtu3_plat.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.h



As Oliver already said, this patch is quiet big which makes it difficult
to review.
I propose to provide a first implementation with minimal functionality
and incremental patches on top of this when the first got merged.

You could split the patch in three series/parts:
1. Host only
2. Peripheral only
3. Dual mode

What do you think?


Ok, I'll split the patch into some small ones as many as possible.


There is no direct policy how to do that and it depends a bit on every 
maintainer what he prefers. As a rule of thumb each commit should 
compile on it's own without errors. This makes bisecting the kernel much 
easier.


Regards,
Matthias



Thanks a lot


Regards,
Matthias





--
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: usbip: vhci extension: modifications to vhci driver

[Dan Carpenter]

Hello Nobuo Iwata,

This is a semi-automatic email about new static checker warnings.

The patch 0775a9cbc694: "usbip: vhci extension: modifications to vhci 
driver" from Jun 13, 2016, leads to the following Smatch complaint:

drivers/usb/usbip/vhci_hcd.c:466 vhci_tx_urb()
 warn: variable dereferenced before check 'vdev' (see line 463)

drivers/usb/usbip/vhci_hcd.c
   462  struct vhci_priv *priv;
   463  struct vhci_hcd *vhci = vdev_to_vhci(vdev);
^^
Patch adds a new dereference inside the vdev_to_vhci() function.

   464  unsigned long flags;
   465  
   466  if (!vdev) {
^
Old code assumed "vdev" could be NULL.

   467  pr_err("could not get virtual device");
   468  return;

regards,
dan carpenter
--
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: Interactive whiteboards

[Greg KH]

On Mon, Oct 10, 2016 at 10:54:07PM +0200, María Cano wrote:
> The Linux kernel supports many devices and each day more and more are
> included, but there is a device that looks completely abandoned:
> whiteboards. In my immediate environment a lot of interactive
> whiteboards do not work under linux. Except some Smartboards, all
> other lack support (Multiclass, Promethean, eBeam, iQBoard, Hitachi
> Starboard, etc...). If you're lucky the manufacturer takes some sort
> of proprietary module for a specific kernel version and does not
> update more, leaving it :-(
> Please, could someone get their hands on this? I do not know
> programming in C, but I'm experienced linux user and I have at my
> disposal a large number of interactive whiteboards of many different
> brands to test, give information and try anything.

I thought these were "just" HID devices?  What does the output of
cat /sys/kernel/debug/usb/devices
say with the devices plugged in?

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