> > - Although i removed the dependency from ezusb to usb_serial,
> > ezusb.c still resides in drivers/usb/serial.
> > Can you give me a hint, where to put it instead?
> > I would like to do that with an additional patch.
>
> Why do you want to move it?
because is has nothing to do with an
On Tue, Aug 21, 2012 at 06:22:35PM -0700, Kevin Cernekee wrote:
Just one thing that bit while I was sleeping:
The HW acks SetConfig on its own. Once you notice this, you set
->ep0_req_set_cfg and set state in bcm63xx_ep0_do_idle() to
EP0_IN_FAKE_STATUS_PHASE. This is I guess the workaround for mas
Add ocp2scp data node in omap4 device tree file.
Acked-by: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap4.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 04cbbcb..8a780b2 100644
This patch series has been lying here for long. If no one has any
comments on this patch series, can someone pick it up?
This patch series is done as a preparatory step for adding phy drivers
for dwc3 and musb.
This series adds a new driver for ocp2scp (only dt) to which phy
drivers are connected
Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of
creating all the devices that is connected to OCP2SCP. In the case of OMAP4,
USB2PHY is connected to ocp2scp.
This also includes device tree support for ocp2scp driver and
the documentation with device tree binding informati
Hi Felip,
I am already discussing it with SNPS, but if you have observed following
with current code..
Out of two generation condition for missed isoc, only first is handled
with current code.
1. when the host does not poll for all the data.
2. because of application-side delays that preven
On Tue, Aug 21, 2012 at 10:47 PM, Tony Prisk wrote:
> Converted the existing arch-vt8500 gpio to a platform_device.
> Added support for WM8505 and WM8650 GPIO controllers.
(...)
> + unsigned val;
I asked about the datatype for this "val", it sure isn't "unsigned".
I suspected the register
On 22 August 2012 11:48, Felipe Balbi wrote:
> Hi,
>
> On Wed, Aug 22, 2012 at 11:13:16AM +0530, Sachin Kamat wrote:
>> Replace printk with corresponding pr_* functions.
>>
>> Signed-off-by: Sachin Kamat
>> ---
>> drivers/usb/gadget/s3c2410_udc.c | 12 +++-
>> 1 files changed, 7 insert
Fixes the following checkpatch errors:
ERROR: do not use assignment in if condition
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c2410_udc.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/s3c2410_udc.c b/drivers/usb/gadget/s3c2410_udc.c
i
'req' being a pointer shouldn't be equated with 0.
Fixes the following compilation warning:
drivers/usb/gadget/s3c2410_udc.c:1299:13: warning:
Using plain integer as NULL pointer
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c2410_udc.c |2 +-
1 files changed, 1 insertions(+), 1 dele
Silences about 75 errors and warnings related to
- Spacing
- Alignment of braces
- Line over 80 characters
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c2410_udc.c | 124 ++---
1 files changed, 60 insertions(+), 64 deletions(-)
diff --git a/drivers/usb/g
Replace printk with corresponding pr_* and dev_err functions.
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c2410_udc.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/s3c2410_udc.c b/drivers/usb/gadget/s3c2410_udc.c
index 7acecc0..55
Fixes the following warning:
WARNING: Use #include instead of
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c2410_udc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/s3c2410_udc.c b/drivers/usb/gadget/s3c2410_udc.c
index f2e51f5..7acecc0 10
This patch series fixes several errors and warnings related to coding style
and compilation in s3c2410_udc driver.
It is compile tested using s3c2410_defconfig based on linux-next tree.
Changes since v1:
Patch2: Used dev_err in function where struct device was accessible.
Other patches rebased due
when missing USB PHY clock, kernel booting up will hang during USB
initialization. We should check USBGP[PHY_CLK_VALID] bit to avoid
CPU hanging in this case.
Signed-off-by: Shengzhou Liu
---
v2 changes: use spin_event_timeout() instead.
drivers/usb/host/ehci-fsl.c | 58 ++
Hi,
On Wed, Aug 22, 2012 at 02:39:50PM +0530, Pratyush Anand wrote:
> Hi Felip,
>
> I am already discussing it with SNPS, but if you have observed
> following with current code..
>
> Out of two generation condition for missed isoc, only first is
> handled with current code.
>
> 1. when the host
Hi,
On Wed, Aug 15, 2012 at 09:59:13PM +0200, Sebastian Andrzej Siewior wrote:
> This pertly reverts 07a18bd7 ("usb gadget: don't save bind callback in
> struct usb_composite_driver") and fixes new drivers. The section missmatch
> problems was solved by whitelisting bind callback in modpost.
>
>
Apps which deal with devices which also have a kernel driver, need to do
the following:
1) Check which driver is attached, so as to not detach the wrong driver
(ie detaching usbfs while another instance of the app is using the device)
2) Detach the kernel driver
3) Claim the interface
Where mov
On Wed, Aug 15, 2012 at 09:59:16PM +0200, Sebastian Andrzej Siewior wrote:
> The direct user of the gadget driver (composite, dbgp, inode,
> file_storage) keeps a global variable where it stores a pointer to
> something which identifies the "current" instance from the time calling
> usb_gadget_prob
Hi,
On Mon, Aug 20, 2012 at 09:35:22AM +0200, Sebastian Andrzej Siewior wrote:
> I'm not going to swear here. The Android gadget includes composite.c
> from the main tree and overwrites functions. This would still work if I
> rename it and remove the const attribute but the problem rises again
> o
On 08/22/2012 01:33 PM, Felipe Balbi wrote:
I don't think you should split this from patch 1, otherwise before this
patch no gadget driver will work, right ?
In #1 I have
@@ -1639,7 +1640,8 @@ int usb_composite_probe(struct
usb_composite_driver *driver,
composite_driver.max_speed =
On Fri, Aug 17, 2012 at 03:14:10PM +0200, Sebastian Andrzej Siewior wrote:
> On 08/16/2012 11:31 AM, Roland Stigge wrote:
> >USB_ISP1301 already depends on I2C.
> >
> >Maybe we should rather let USB_LPC32XX "depends on USB_ISP1301" instead
> >of "select USB_ISP1301"?
>
> And your OHCI select has t
On 08/22/2012 01:42 PM, Felipe Balbi wrote:
If ccg needs a different setup method, it's completely non-standard. I
don't think it should be using composite.c at all.
Just make ccg a standalone gadget non-dependent on this composite.c and
let's move on. If later ccg wants to continue to exist in
On 08/22/2012 01:43 PM, Felipe Balbi wrote:
But now that I've seen the transceiver driver it is probably the
smallest one.
if it depends on the transceiver, why do we have i2c transfers on those
drivers ? They should be hidden by the usb_phy_*() calls.
Unless Roland has other plans now I woul
On Wed, Aug 22, 2012 at 01:56:56PM +0200, Sebastian Andrzej Siewior wrote:
> On 08/22/2012 01:43 PM, Felipe Balbi wrote:
> >>But now that I've seen the transceiver driver it is probably the
> >>smallest one.
> >
> >if it depends on the transceiver, why do we have i2c transfers on those
> >drivers ?
On Wednesday 22 August 2012 13:42:47 Hans de Goede wrote:
> Apps which deal with devices which also have a kernel driver, need to do
> the following:
> 1) Check which driver is attached, so as to not detach the wrong driver
>(ie detaching usbfs while another instance of the app is using the dev
>>> Even though it makes me wonder whether f_mass_storage isn't missing
>>> something in its original code.
>>
>> I wondered about that too. The difference is that f_mass_storage uses
>> the composite framework. How does composite handle disconnects and
>> port resets? The framework might need
On Wed, Aug 22, 2012 at 7:30 PM, Miroslav Sabljic
wrote:
> On 08/21/2012 01:33 PM, Andiry Xu wrote:
>
>>> Not sure. it's hard to debug via software side because software seems
>>> does not do anything wrong. If you disable USB3 support in BIOS the
>>> ports are handled by EHCI instead. Perhaps the
Hi,
Thanks for the review!
On 08/22/2012 02:04 PM, Oliver Neukum wrote:
On Wednesday 22 August 2012 13:42:47 Hans de Goede wrote:
Apps which deal with devices which also have a kernel driver, need to do
the following:
1) Check which driver is attached, so as to not detach the wrong driver
On Wednesday 22 August 2012, Kishon Vijay Abraham I wrote:
> This patch series has been lying here for long. If no one has any
> comments on this patch series, can someone pick it up?
I've added them now as a drivers/ocp2scp branch arm-soc and pulled
them into the next/drivers topic branch.
On Wed, Aug 22, 2012 at 6:04 PM, Arnd Bergmann wrote:
> On Wednesday 22 August 2012, Kishon Vijay Abraham I wrote:
>> This patch series has been lying here for long. If no one has any
>> comments on this patch series, can someone pick it up?
>
> I've added them now as a drivers/ocp2scp branch arm-
On 08/22/2012 01:56 PM, Sebastian Andrzej Siewior wrote:
> On 08/22/2012 01:43 PM, Felipe Balbi wrote:
>>> But now that I've seen the transceiver driver it is probably the
>>> smallest one.
>>
>> if it depends on the transceiver, why do we have i2c transfers on those
>> drivers ? They should be hid
This comment says that hub descriptor follows. This is wrong because it
is a BOS descriptor with one capability. Since this is obvious, I remove
the comment.
Signed-off-by: Sebastian Andrzej Siewior
---
On Tue, Aug 21, 2012 at 01:17:33PM -0400, Alan Stern wrote:
> That would be okay.
This is a p
The comment is a quote of Alan Stern and reflects the data structure
better than the the initial comment.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/host/xhci-hub.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host
>> Converted the existing arch-vt8500 gpio to a platform_device.
>> Added support for WM8505 and WM8650 GPIO controllers.
>(...)
>> + unsigned val;
>I asked about the datatype for this "val", it sure isn't "unsigned".
>I suspected the registers were only 8bit and so it should be u8.
>But at
On Wed, 22 Aug 2012, Lan Tianyu wrote:
> >> @@ -1560,6 +1560,10 @@ static int hub_configure(struct usb_hub *hub,
> >>dev_err(hub->intfdev,
> >>"couldn't create port%d device.\n", i + 1);
> >>
> >> + /* Get hub descriptor again to sync port's Devi
On Wed, 22 Aug 2012, Lan Tianyu wrote:
> > You forgot to change the logic in hub_power_on(). You have to handle
> > the USB_PORT_POWER_AUTO case.
> Yeah. Thanks for reminder.
> How about following?
>
> @@ -858,7 +860,14 @@ static unsigned hub_power_on(struct usb_hub *hub,
> bool do_delay)
>
On Thu, Jul 19, 2012 at 12:20:11AM +0200, Michael Grzeschik wrote:
> The lockdep hunter mentions a non consistent usage of spin_lock and
> spin_lock_irqsafe in the composite_disconnect and usb_function_activate
> function:
>
> [ 15.700897] =
> [ 15.705255] [ INF
v1..v2:
- use __ref instead hack in modpost
- give Android's gadget a copy of composite.c.
Sebastian
--
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
It was moved to be an argument in 07a18bd716ed5 ("usb gadget: don't
save bind callback in struct usb_composite_driver"). The reason was to
avoid the section missmatch. The warning was shown because ->bind is
marked as __init becuase it is a one time init. The warning can be also
suppresed by whitel
As it turns out, Sam's comment was better than I initially assumed. This
patch pushes as struct usb_composite_driver data structures into
__refdata section to avoid a section missmatch report from modpost
because the ->bind() can be marked __init. The only downside is that
modpost does not check be
This partly reverts 07a18bd7 ("usb gadget: don't save bind callback in
struct usb_composite_driver") and fixes new drivers. The section missmatch
problems was solved by whitelisting structs in question via __ref.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/staging/ccg/ccg.c |
The ret variable is not initialized and therefore random. I guess the
Android compiler is doing this right :P
Cc: de...@driverdev.osuosl.org
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/staging/ccg/ccg.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/stagi
This partly reverts 07a18bd7 ("usb gadget: don't save bind callback in
struct usb_composite_driver") and fixes new drivers. The section missmatch
problems was solved by whitelisting bind callback in modpost.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/gadget/composite.c|3 ++
The Android gadgets does a few things wrong and keeping them working is
a bad example _and_ they should be solved differntly. Since it makes
further composite.c changes very difficult, ccg has its own copy for
now.
Cc: de...@driverdev.osuosl.org
Signed-off-by: Sebastian Andrzej Siewior
---
drive
The direct user of the gadget driver (composite, dbgp, inode,
file_storage) keeps a global variable where it stores a pointer to
something which identifies the "current" instance from the time calling
usb_gadget_probe_driver() and later in its ->bind() callback.
This patch passes the struct usb_gad
于 2012/8/22 22:32, Alan Stern 写道:
On Wed, 22 Aug 2012, Lan Tianyu wrote:
@@ -1560,6 +1560,10 @@ static int hub_configure(struct usb_hub *hub,
dev_err(hub->intfdev,
"couldn't create port%d device.\n", i + 1);
+ /* Get hub descriptor
于 2012/8/22 22:39, Alan Stern 写道:
On Wed, 22 Aug 2012, Lan Tianyu wrote:
You forgot to change the logic in hub_power_on(). You have to handle
the USB_PORT_POWER_AUTO case.
Yeah. Thanks for reminder.
How about following?
@@ -858,7 +860,14 @@ static unsigned hub_power_on(struct usb_hub *hub,
b
On Wed, 22 Aug 2012, Hans de Goede wrote:
> Apps which deal with devices which also have a kernel driver, need to do
> the following:
> 1) Check which driver is attached, so as to not detach the wrong driver
>(ie detaching usbfs while another instance of the app is using the device)
> 2) Detac
On Wed, 22 Aug 2012, Michael Grzeschik wrote:
> On Thu, Jul 19, 2012 at 12:20:11AM +0200, Michael Grzeschik wrote:
> > The lockdep hunter mentions a non consistent usage of spin_lock and
> > spin_lock_irqsafe in the composite_disconnect and usb_function_activate
> > function:
> >
> > [ 15.70089
On Thu, Jul 19, 2012 at 12:20:11AM +0200, Michael Grzeschik wrote:
> The lockdep hunter mentions a non consistent usage of spin_lock and
> spin_lock_irqsafe in the composite_disconnect and usb_function_activate
> function:
[...]
> Signed-off-by: Michael Grzeschik
Acked-by: Michal Nazarewicz
On Wed, 22 Aug 2012, Lan Tianyu wrote:
> >> At first time, the usb port devices have not been created and not bound
> >> with acpi. So at that time, port's DeviceRemovable is not set according
> >> acpi information. After ports' devices are created, binding procedure is
> >> completed. Request hub
Alan Stern writes:
> On Wed, 22 Aug 2012, Michael Grzeschik wrote:
>
>> On Thu, Jul 19, 2012 at 12:20:11AM +0200, Michael Grzeschik wrote:
>> > The lockdep hunter mentions a non consistent usage of spin_lock and
>> > spin_lock_irqsafe in the composite_disconnect and usb_function_activate
>> > fu
Hi,
On 08/22/2012 05:05 PM, Alan Stern wrote:
On Wed, 22 Aug 2012, Hans de Goede wrote:
Apps which deal with devices which also have a kernel driver, need to do
the following:
1) Check which driver is attached, so as to not detach the wrong driver
(ie detaching usbfs while another instance
On Wed, 22 Aug 2012, Sebastian Andrzej Siewior wrote:
> The direct user of the gadget driver (composite, dbgp, inode,
> file_storage) keeps a global variable where it stores a pointer to
> something which identifies the "current" instance from the time calling
> usb_gadget_probe_driver() and later
On 08/22/2012 02:20 PM, Andiry Xu wrote:
If the device is working properly on boot up and fails after
suspend/resume, you can try the patch attached to see if it helps on
the failure after system resume.
Unfortunately it look like it doesn't change anything. Patched, rebuilt,
installed and te
On Wed, 22 Aug 2012, Hans de Goede wrote:
> >> + if ((dc.flags & USBDEVFS_DISCONNECT_CLAIM_IF_DRIVER) &&
> >> + strncmp(dc.driver, intf->dev.driver->name,
> >> + sizeof(dc.driver)) != 0)
> >> + return -EBUSY;
> >> +
> >> +
Hi,
[1.] One line summary of the problem:
Certain USB devices wake up the system after power off
[2.] Full description of the problem/report:
The computer no longer shuts down properly after upgrading from Ubuntu
11.04 to 11.10 (this is from kernel 2.6.38 to 3.0.20 (*)), it powers on
immediat
If this is a must-to-do thing for Intel Panther Point platform, then
we need to make sure it's called on power up and resume. Yes, I think
moving the code below hc_init label should work and I think it's a
better solution than your original patch.
Yes it effects a lot of machines (Lenovo), I w
On 08/22/2012 05:28 PM, Alan Stern wrote:
Pardon me for being stupid, but I don't understand this description at
all. Example one, on the first line: How is file_storage a direct user
of the gadget driver? It _is_ the gadget driver!
I meant the fact that that file_storage is using struct
usb_
On Wed, 22 Aug 2012, Àlex Magaz Graça wrote:
> Hi,
>
> [1.] One line summary of the problem:
> Certain USB devices wake up the system after power off
>
> [2.] Full description of the problem/report:
>
> The computer no longer shuts down properly after upgrading from Ubuntu
> 11.04 to 11.10 (th
From: Manoj Iyer
On Intel Panther Point chipset USB 3.0 devices show up as
high-speed devices on powerup, but after an s3 cycle they are
correctly recognized as SuperSpeed. At powerup switch the port
to xHCI so that USB 3.0 devices are correctly recognized.
This is a second attempt at fixing thi
From: Manoj Iyer
On Intel Panther Point chipset USB 3.0 devices show up as
high-speed devices on powerup, but after an s3 cycle they are
correctly recognized as SuperSpeed. At powerup switch the port
to xHCI so that USB 3.0 devices are correctly recognized.
BugLink: http://bugs.launchpad.net/bug
On 8/22/2012 5:01 PM, Felipe Balbi wrote:
Hi,
On Wed, Aug 22, 2012 at 02:39:50PM +0530, Pratyush Anand wrote:
Hi Felip,
I am already discussing it with SNPS, but if you have observed
following with current code..
Out of two generation condition for missed isoc, only first is
handled with curr
The gadget case is, just depend on the ISP1301 instead of selecting it.
The OHCI case is little more difficult. It is not possible to say select
if and on top of it, the phy depends on USB which depends on OHCI. This
started as a fix for:
| drivers/usb/gadget/lpc32xx_udc.c: In function ‘isp1301_ud
|drivers/usb/gadget/pxa25x_udc.h: In function 'dump_state':
|drivers/usb/gadget/pxa25x_udc.h:228:20: error: invalid type argument of '->'
(have 'struct usb_ep')
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/gadget/pxa25x_udc.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Wed, 22 Aug 2012, Sebastian Andrzej Siewior wrote:
> The gadget case is, just depend on the ISP1301 instead of selecting it.
> The OHCI case is little more difficult. It is not possible to say select
> if and on top of it, the phy depends on USB which depends on OHCI. This
Let's see if I under
On Sat, Aug 18, 2012 at 08:16:12PM -0400, Alan Stern wrote:
> On Sat, 18 Aug 2012, Alan Stern wrote:
>
> > > Looking at the output of usbmon, the kernel re-uses URB addresses. Is it
> > > possible that the urb is freed while the instruction is in
> > > *implement()*?
> >
> > In fact, the usbhid d
On 08/21/2012 02:47 PM, Tony Prisk wrote:
> Bindings for gpio, interrupt controller, power management controller,
> timer, realtime clock, serial uart, ehci and uhci controllers and
> framebuffer controllers used on the arch-vt8500 platform.
>
> Framebuffer binding also specifies a 'display' node
On Wed, 22 Aug 2012, Amit Uttamchandani wrote:
> > One thing to look out for: Evidently usbhid_submit_report() does not
> > check the HID_DISCONNECTED flag and will happily allow reports to be
> > submitted after usbhid_stop() returns. This appears to be a bug. It
> > could account for the b
On Wed, 2012-08-22 at 15:07 -0600, Stephen Warren wrote:
> On 08/21/2012 02:47 PM, Tony Prisk wrote:
> > Bindings for gpio, interrupt controller, power management controller,
> > timer, realtime clock, serial uart, ehci and uhci controllers and
> > framebuffer controllers used on the arch-vt8500 pl
Hi,
New USB input driver for eBeam devices.
Currently supported (tested) :
- Luidia eBeam classic projection and edge projection models
- Nec "interactive solution" NP01Wi1 & NP01Wi2 accessories.
In fact, from basic usb point of view, all these devices are
indistinguishable : they have the same
Signed-off-by: Yann Cantin
---
drivers/hid/hid-core.c |3 +++
drivers/hid/hid-ids.h |3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 60ea284..efc68c8 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1908,6 +
Signed-off-by: Yann Cantin
---
drivers/input/misc/Kconfig | 22 ++
drivers/input/misc/Makefile |1 +
drivers/input/misc/ebeam.c | 766 +++
3 files changed, 789 insertions(+)
create mode 100644 drivers/input/misc/ebeam.c
diff --git a/drivers/inpu
Hi,
On 22/08/12 21:49, Alan Stern wrote:
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index c3f619b..cac3ee2 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -292,7 +292,6 @@ config USB_OHCI_HCD
>> depends on USB && USB_ARCH_HAS_OHCI
>
Le Wed, 15 Aug 2012 10:53:07 -0400 (EDT),
Alan Stern a écrit :
> On Tue, 14 Aug 2012, Laurent Bigonville wrote:
>
> > > But does the UPS work okay when you use the parameter? If it
> > > does, the quirk information can be added to a permanent table in
> > > the usbhid driver.
> >
> > Yes it se
renesas_usbhs dma can transport 8byte alignment data, not 4byte.
This patch fixup it.
Reported-by: Sugnan Prabhu S
Signed-off-by: Kuninori Morimoto
---
drivers/usb/renesas_usbhs/fifo.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/fifo.c b
On 08/07/2012 11:39 AM, Sarah Sharp wrote:
The Intel desktop boards DH77EB and DH77DF have a hardware issue that
can be worked around by BIOS. If the USB ports are switched to xHCI on
shutdown, the xHCI host will send a spurious interrupt, which will wake
the system. Some BIOS will work around
On 2012年08月22日 23:18, Alan Stern wrote:
> On Wed, 22 Aug 2012, Lan Tianyu wrote:
>
At first time, the usb port devices have not been created and not bound
with acpi. So at that time, port's DeviceRemovable is not set according
acpi information. After ports' devices are created, bind
79 matches
Mail list logo
