The Chipidea i.MX driver has some issues with module loading dependencies.
This fixes this. It is an alternative approach to the one Peter Chen
suggested that does without changing the dt binding.
Sascha
Sascha Hauer (2):
USB:
Signed-off-by: Sascha Hauer
---
drivers/usb/chipidea/ci_hdrc_imx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 14362c0..11ed423 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hd
The chipidea i.MX driver is split into two drivers. The ci_hdrc_imx driver
handles the chipidea cores and the usbmisc_imx driver handles the noncore
registers common to all chipidea cores (but SoC specific). Current flow is:
- usbmisc sets an ops pointer in the ci_hdrc_imx driver during probe
- ci
On Thu, Aug 08, 2013 at 06:19:43PM +0800, Peter Chen wrote:
> > > - compatible = "fsl,imx25-usbmisc";
> > > - clocks = <&clks 9>, <&clks 70>, <&clks 8>;
> > > - clock-names = "ipg", "ahb", "per";
> > > -
> On Thu, Aug 08, 2013 at 03:38:53AM +, Wang, Yu Y wrote:
> > > Hi Felipe,
> > >
> > > This patch brings up an interesting point: will a dwc3 PCI host use
> > > the xhci platform driver instead of the xhci PCI driver?
> > >
> > > If so, that seems less than ideal. Won't it not use the standard
Hi Ben, David and Andrew,
We are appreciative of your help and happy to see that.
Acked-by: Danny Lin
Thank you very much.
Danny.
-Original Message-
From: Ben Hutchings [mailto:b...@decadent.org.uk]
Sent: Friday, August 09, 2013 5:00 AM
To: Andrew Lunn
Cc: Danny Lin (林政易); dw...@infr
Christian Lamparter wrote:
> So, if we call usb_reset_device there and the driver is unbound
> and later rebound. the next ath9k_htc .probe will start again and
> again and again not knowing that it is already initialized
> (and we have a loop).
The HW/FW is buggy and this workaround is required:
> Sorry, I don't understand what is not implemented. Without your patch, the
> PHY driver handles both PMU registers of Exynos4.
I don't have an Exynos4 to actually test this, so please let me know
if I'm missing something here... but in order to hit the right HOST
PHY register in the current upst
> Hi Yu,
>
> Please test this patch, and make sure that interrupts aren't registered twice.
> I think this approach is better, since it creates a new quirk specifically
> for xhci
> platform devices, so we can tell them apart from PCI devices.
[Yu:] Yes. This patch is working for me. This is one
On Thu, Aug 08, 2013 at 07:12:13PM -0700, Jack Pham wrote:
> Hi Greg,
>
> On Thu, Aug 08, 2013 at 05:05:41PM -0700, Greg KH wrote:
> > I don't seem to have a patch 1/2 from you, did it not get sent somehow?
>
> Here was patch 1/2: http://marc.info/?l=linux-usb&m=137282127113409&w=2
> which you've
Hi Greg,
On Thu, Aug 08, 2013 at 05:05:41PM -0700, Greg KH wrote:
> I don't seem to have a patch 1/2 from you, did it not get sent somehow?
Here was patch 1/2: http://marc.info/?l=linux-usb&m=137282127113409&w=2
which you've applied to usb-next already as commit 1353aa53. I kept the
sequence numb
On Fri, Aug 9, 2013 at 8:18 AM, Grant Grundler wrote:
> Ming,
> We are splitting hairs now. :) I want to be clear I think your changes
> are good and the rest of this conversation is just to learn something
> new.
>
> On Thu, Aug 8, 2013 at 4:48 PM, Ming Lei wrote:
>> On Fri, Aug 9, 2013 at 1:25
In isp1760-hcd driver, flush_dcache_page() is introduced in commit
db8516f61b4(USB: isp1760: Flush the D-cache for the pipe-in transfer buffers)
to fix cache incoherency problem when PIO reading from USB mass storage
device to mapped page, so the flush should not need for slab pages which
won't be
On Thu, Aug 08, 2013 at 05:24:46PM -0700, Alexandra Yates wrote:
> Modified the xHCI roothub descriptor to return USB2.0 extension
> descriptor Best Effort Service Latency (BESL) and Deep Best Effort
> Service Latency (DBESL) values when set on the xHCI host.
>
> On link power management the BESL
Modified the xHCI roothub descriptor to return USB2.0 extension
descriptor Best Effort Service Latency (BESL) and Deep Best Effort
Service Latency (DBESL) values when set on the xHCI host.
On link power management the BESL and DBESL values are used to
estimate L1 exit latency for USB2.0 host and d
Modified the xHCI roothub descriptor to return USB2.0 extension
descriptor Best Effort Service Latency (BESL) and Deep Best Effort
Service Latency (DBESL) values when set on the xHCI host.
On link power management the BESL and DBESL values are used to
estimate L1 exit latency for USB2.0 host and d
Ming,
We are splitting hairs now. :) I want to be clear I think your changes
are good and the rest of this conversation is just to learn something
new.
On Thu, Aug 8, 2013 at 4:48 PM, Ming Lei wrote:
> On Fri, Aug 9, 2013 at 1:25 AM, Grant Grundler wrote:
...
>>> I am afraid that PCI network dev
On Thu, Aug 08, 2013 at 04:49:24PM -0700, Jack Pham wrote:
> From: Manu Gautam
I don't seem to have a patch 1/2 from you, did it not get sent somehow?
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
M
From: Manu Gautam
The USB Embedded High-speed Host Electrical Test (EHSET) defines the
SINGLE_STEP_SET_FEATURE test as follows:
1) The host enumerates the test device with VID:0x1A0A, PID:0x0108
2) The host sends the SETUP stage of a GetDescriptor(Device)
3) The device ACKs the request
4) The ho
On Fri, Aug 9, 2013 at 1:25 AM, Grant Grundler wrote:
> On Tue, Aug 6, 2013 at 5:41 PM, Ming Lei wrote:
>> On Wed, Aug 7, 2013 at 1:09 AM, Grant Grundler wrote:
> ...
>>> Following that logic, shouldn't all the features/hw_features settings
>>> be removed from reset code path?
>>
>> This patch w
rh_call_control() contains a buffer, tbuf, which it uses to hold
USB descriptors. These discriptors are eventually copied into the
transfer_buffer in the URB. The buffer in the URB is dynamically
defined and is always large enough to hold the amount of data it
requests.
tbuf is currently staticall
My apologies. This is my first attempt at submitting a patch, so I am
unfamiliar with some of the procedures. I will resend this revision of the
patch with the proper [PATCH] tag.
-Sean
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, August 08,
Note, I don't apply "RFC" patches, and rarely review them. Why are you
claiming that is what this is, when it is in the 3rd version already?
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 a
rh_call_control() contains a buffer, tbuf, which it uses to hold
USB descriptors. These discriptors are eventually copied into the
transfer_buffer in the URB. The buffer in the URB is dynamically
defined and is always large enough to hold the amount of data it
requests.
tbuf is currently staticall
Ahh! Good point. Will resend the patch. :)
Thank you,
Alexandra.
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org]
On Behalf Of Greg KH
Sent: Thursday, August 08, 2013 2:12 PM
To: Yates, Alexandra
Cc: linux-usb@vger.kernel.org
Subject
On Thursday 08 August 2013 22:19:32 Alan Stern wrote:
> On Thu, 8 Aug 2013, Christian Lamparter wrote:
>
> > Anyway, I do have a question about something else too.
> >
> > in ath9k_htc's hif_usb:
> >
> > > struct usb_host_interface *alt = &hif_dev->interface->altsetting[0];
> > > struct usb_endp
Hi Julius,
On Thursday 08 of August 2013 11:06:54 Julius Werner wrote:
> > I'm not sure I understand. The old documentation referred to the
> > USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers for a phy, and
> > your new version only refers to (usb device) PHY_CONTROL. Regardless
> > of
> >
On Thu, Aug 08, 2013 at 05:52:53PM +0200, mario tillmann wrote:
> With the latest kernel 3.10.x I get an error message when loading the firmware
> sms1xxx-hcw-55xxx-dvbt-02.fw:
>
> smscore_load_firmware_family2: line: 986: sending
> MSG_SMS_DATA_VALIDITY_REQ expecting 0xcfed1755
> smscore_onrespon
On Thu, Aug 08, 2013 at 02:05:53PM -0700, Alexandra Yates wrote:
> Modified xHCI roothub descriptor to return USB2.0 extension descriptor
> with BESL and DBESL values set when these values are set on the xHCI
> host.
Why would we want this? What benefit or bug does this fix?
You need to explain
Modified xHCI roothub descriptor to return USB2.0 extension descriptor
with BESL and DBESL values set when these values are set on the xHCI
host.
Curretnly the root hub device descriptor values are set to zero by the
BIOS. Therefore to test this functionality with lsusb, I hard coded
the usb2_rh_d
Modified xHCI roothub descriptor to return USB2.0 extension descriptor
with BESL and DBESL values set when these values are set on the xHCI
host.
Curretnly the root hub device descriptor values are set to zero by the
BIOS. Therefore to test this functionality with lsusb, I hard coded
the usb2_rh_
On Thu, 2013-08-08 at 12:20 +0200, Andrew Lunn wrote:
> Hi Ben, David
>
> Here is a pull request for firmware for Moxa USB-Serial hub devices.
>
> Thanks
> Andrew
>
> The following changes since commit 931e4469dc254df66a2c990ff1a8723685759eb4:
>
> radeon: add ucode for KABINI GPUs (2013
On Thu, 8 Aug 2013, Sean O. Stalley wrote:
> rh_call_control() contains a buffer, tbuf, which it uses to hold
> USB descriptors. These discriptors are eventually copied into the
> transfer_buffer in the URB. The buffer in the URB is dynamically
> defined and is always large enough to hold the amou
rh_call_control() contains a buffer, tbuf, which it uses to hold
USB descriptors. These discriptors are eventually copied into the
transfer_buffer in the URB. The buffer in the URB is dynamically
defined and is always large enough to hold the amount of data it
requests.
tbuf is currently staticall
Prevent the USB core from suspending the HWA root hub since bus_suspend
and bus_resume are not yet supported. Otherwise the PM system will chew
up CPU time constantly attempting to suspend and resume the root hub but
never succeeding.
Signed-off-by: Thomas Pugliese
diff --git a/drivers/usb/h
On Thu, 8 Aug 2013, Christian Lamparter wrote:
> Anyway, I do have a question about something else too.
>
> in ath9k_htc's hif_usb:
>
> > struct usb_host_interface *alt = &hif_dev->interface->altsetting[0];
> > struct usb_endpoint_descriptor *endp;
> > ...
> > /* On downloading the firmware to t
Hi,
I get plenty of these in /sys/kernel/debug/kmemleak:
unreferenced object 0x88019f675268 (size 32):
comm "usb-storage", pid 11411, jiffies 4310515592 (age 1538.100s)
hex dump (first 32 bytes):
05 0f 16 00 02 07 10 02 02 00 00 00 0a 10 03 00
0e 00 01 0a ff 07
Hello.
On 08/08/2013 11:41 PM, Thomas Pugliese wrote:
Prevent the USB core from suspending the HWA root hub since bus_suspend
and bus_resume are not yet supported. Otherwise the PM system will chew
up CPU time constantly attempting to suspend and resume the root hub but
never succeeding.
Si
On 08.08.2013 18:14, Petko Manolov wrote:
> On Wed, 7 Aug 2013, Jussi Kivilinna wrote:
>
>> rtl8150 allocates URB transfer_buffer and setup_packet as part of same
>> structure 'struct async_req'. This can cause same cacheline to be
>> DMA-mapped twice with same URB. This can lead to memory corru
Prevent the USB core from suspending the HWA root hub since bus_suspend
and bus_resume are not yet supported. Otherwise the PM system will chew
up CPU time constantly attempting to suspend and resume the root hub but
never succeeding.
Signed-off-by: Thomas Pugliese
diff --git a/drivers/usb/h
On Thursday 08 August 2013 17:35:34 Oleksij Rempel wrote:
> Am 31.07.2013 08:52, schrieb Oleksij Rempel:
> > Am 28.07.2013 22:41, schrieb Christian Lamparter:
> >> On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
> >>> Am 28.07.2013 14:12, schrieb Oleksij Rempel:
> Am 28.07.2013 13:3
> I'm not sure I understand. The old documentation referred to the
> USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers for a phy, and
> your new version only refers to (usb device) PHY_CONTROL. Regardless of
> multiple phys, you're suggesting that we describe less of each phy.
> That seems li
Hi Yu,
Please test this patch, and make sure that interrupts aren't registered
twice. I think this approach is better, since it creates a new quirk
specifically for xhci platform devices, so we can tell them apart from
PCI devices.
Sarah Sharp
>8-
On Tue, Aug 6, 2013 at 5:41 PM, Ming Lei wrote:
> On Wed, Aug 7, 2013 at 1:09 AM, Grant Grundler wrote:
...
>> Following that logic, shouldn't all the features/hw_features settings
>> be removed from reset code path?
>
> This patch won't touch other settings because that isn't related with
> this
The hub_status_data function on the wireless USB root hub controller
(wusbhc_rh_status_data) always returns a positive value even if no ports
have changed. This patch updates wusbhc_rh_status_data to only return a
positive value if the root hub status needs to be queried. The current
implemen
On Thu, Aug 08, 2013 at 03:38:53AM +, Wang, Yu Y wrote:
> > Hi Felipe,
> >
> > This patch brings up an interesting point: will a dwc3 PCI host use the xhci
> > platform driver instead of the xhci PCI driver?
> >
> > If so, that seems less than ideal. Won't it not use the standard xHCI PCI
>
On Thu, 2013-08-08 at 21:48 +0800, Ming Lei wrote:
> This patch marks all xHCI controllers as no_sg_constraint
> since xHCI supports building packet from discontinuous buffers.
>
> Cc: Alan Stern
> Acked-by: Sarah Sharp
> Signed-off-by: Ming Lei
> ---
> drivers/usb/host/xhci.c |4
> 1
On Thu, 2013-08-08 at 21:48 +0800, Ming Lei wrote:
> This patch introduces support of DMA SG if the USB host controller
> which usbnet device is attached to is capable of building packet from
> discontinuous buffers.
> diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
> index 8
On Thu, 2013-08-08 at 21:48 +0800, Ming Lei wrote:
> Some host controllers(such as xHCI) can support building
> packet from discontinuous buffers, so introduce one flag
> and helper for this kind of host controllers, then the
> feature can help some applications(such as usbnet) by
> supporting arbi
On Thu, 2013-08-08 at 21:48 +0800, Ming Lei wrote:
> This patch enables 'can_dma_sg' flag for ax88179_178a device
> if the attached host controller supports building packet from
> discontinuous buffers(DMA SG is possible), so TSO can be enabled
> and skb fragment buffers can be passed to usb stack
On 08/08/2013 09:43 AM, Andrzej Pietrasiewicz wrote:
> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
> index c5d8f81..8cb5006 100644
> --- a/drivers/usb/gadget/configfs.c
> +++ b/drivers/usb/gadget/configfs.c
> @@ -866,8 +866,10 @@ static int configfs_composite_bind(str
With the latest kernel 3.10.x I get an error message when loading the firmware
sms1xxx-hcw-55xxx-dvbt-02.fw:
smscore_load_firmware_family2: line: 986: sending
MSG_SMS_DATA_VALIDITY_REQ expecting 0xcfed1755
smscore_onresponse: line: 1565: MSG_SMS_DATA_VALIDITY_RES, checksum = 0xcfed1755
This error
On Wed, 7 Aug 2013, Jussi Kivilinna wrote:
> rtl8150 allocates URB transfer_buffer and setup_packet as part of same
> structure 'struct async_req'. This can cause same cacheline to be
> DMA-mapped twice with same URB. This can lead to memory corruption on
> some systems.
I can see performance
Am 31.07.2013 08:52, schrieb Oleksij Rempel:
Am 28.07.2013 22:41, schrieb Christian Lamparter:
On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
Am 28.07.2013 14:12, schrieb Oleksij Rempel:
Am 28.07.2013 13:38, schrieb Christian Lamparter:
before rmmod.
Oh, I it was on the lat
In the disconnect routine for the hwa_hc interface, it calls
uwb_pal_unregister to unregister itself from the UWB subsystem. This
function attempts to clean up the link to the host controller directory in
the device's UWB radio control interface directory. If the disconnect
routine for the ra
I've heard there's little to do at the software level, but I haven't
been following the spec closely. Are you volunteering to add support?
Sarah Sharp
On Thu, Aug 08, 2013 at 06:16:54PM +0530, Rajaram R wrote:
> Hi All
>
> Can someone share thoughts if there is a work in progress or plan on
> U
This patch enables 'can_dma_sg' flag for ax88179_178a device
if the attached host controller supports building packet from
discontinuous buffers(DMA SG is possible), so TSO can be enabled
and skb fragment buffers can be passed to usb stack via urb->sg
directly.
With the patch, system CPU utilizati
Some host controllers(such as xHCI) can support building
packet from discontinuous buffers, so introduce one flag
and helper for this kind of host controllers, then the
feature can help some applications(such as usbnet) by
supporting arbitrary length of sg buffers.
Acked-by: Alan Stern
Signed-off
This patch introduces support of DMA SG if the USB host controller
which usbnet device is attached to is capable of building packet from
discontinuous buffers.
The patch supports passing the skb fragment buffers to usb stack directly
via urb->sg.
Cc: Eric Dumazet
Cc: Ben Hutchings
Cc: Grant Gru
This patch marks all xHCI controllers as no_sg_constraint
since xHCI supports building packet from discontinuous buffers.
Cc: Alan Stern
Acked-by: Sarah Sharp
Signed-off-by: Ming Lei
---
drivers/usb/host/xhci.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/host/xhci.c
Hi,
This patchset allows drivers to pass sg buffers which size can't be divided
by max packet size of endpoint if the host controllers(such ax xHCI) support
this kind of sg buffers.
Previously we added check[1] on the situation and don't allow these sg buffers
passed to USB HCD, looks the check i
Hi All
Can someone share thoughts if there is a work in progress or plan on
USB power delivery support for Linux ?
Rajaram
--
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/
On Thu, Aug 08, 2013 at 12:38:59PM +0200, Sascha Hauer wrote:
> On Thu, Aug 08, 2013 at 03:33:01PM +0800, Peter Chen wrote:
> > Since ci_hdrc_imx and usbmisc_imx has relationship between each other,
> > they can't be existed as two modules. We change the code, and make
> > the usbmisc_imx has no lo
From: Mark Brown
Systems with the common clock API need clk_prepare() as well as the enable
step.
Signed-off-by: Mark Brown
---
drivers/usb/phy/phy-nop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-nop.c b/drivers/usb/phy/phy-nop.c
index f52b7f8.
On Thu, Aug 08, 2013 at 03:33:01PM +0800, Peter Chen wrote:
> Since ci_hdrc_imx and usbmisc_imx has relationship between each other,
> they can't be existed as two modules. We change the code, and make
> the usbmisc_imx has no longer a driver.
>
> Due to above reason, we introduce non core registe
Hi Ben, David
Here is a pull request for firmware for Moxa USB-Serial hub devices.
Thanks
Andrew
The following changes since commit 931e4469dc254df66a2c990ff1a8723685759eb4:
radeon: add ucode for KABINI GPUs (2013-07-28 22:39:47 +0100)
are available in the git repository at:
https
On Thu, Aug 8, 2013 at 2:56 PM, Mark Rutland wrote:
> On Wed, Aug 07, 2013 at 06:06:05PM +0100, Julius Werner wrote:
>> > This breaks compatibility, both for an old kernel and a new dt and a new
>> > kernel with an old dt. Is anyone using these bindings?
>>
>> They only affect Samsung SoCs and hav
At former design, both ci13xxx_imx and usbmisc_imx are individual
module, ci13xxx_imx is glue layer for imx usb driver. usbmisc_imx
handles non-core registers which have different register layout
for imx SoC serials, it usually supplies interface for wakeup
setting, PHY setting, etc.
usbmisc_imx u
At imx usb driver, it needs to know the controller id to access
register.
Signed-off-by: Peter Chen
---
arch/arm/boot/dts/imx23.dtsi |1 +
arch/arm/boot/dts/imx28.dtsi |2 ++
arch/arm/boot/dts/imx51.dtsi |4
arch/arm/boot/dts/imx53.dtsi |4
arch/arm/boot/dts/imx
On Wed, Aug 07, 2013 at 06:06:05PM +0100, Julius Werner wrote:
> > This breaks compatibility, both for an old kernel and a new dt and a new
> > kernel with an old dt. Is anyone using these bindings?
>
> They only affect Samsung SoCs and have only been upstream for half a
> year, so I doubt it's he
Since ci_hdrc_imx and usbmisc_imx has relationship between each other,
they can't be existed as two modules. We change the code, and make
the usbmisc_imx has no longer a driver.
Due to above reason, we introduce non core register phandle to know
the non core register, and delete the binding doc fr
At former design, both ci13xxx_imx and usbmisc_imx are individual
module, ci13xxx_imx is glue layer for imx usb driver. usbmisc_imx
handles non-core registers which have different register layout
for imx SoC serials, it usually supplies interface for wakeup
setting, PHY setting, etc.
usbmisc_imx u
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/usbmisc_imx.c | 71 +---
1 files changed, 34 insertions(+), 37 deletions(-)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index ac5a461..545efbf 100644
--- a/drivers/usb/c
To reflect source file name change
Signed-off-by: Peter Chen
---
.../devicetree/bindings/usb/ci13xxx-imx.txt| 31
.../devicetree/bindings/usb/ci_hdrc_imx.txt| 31
Documentation/devicetree/bindings/usb/mxs-phy.txt | 13
...
On Tue, Aug 06, 2013 at 03:36:33PM +0100, Ivan T. Ivanov wrote:
> Hi,
>
> On Tue, 2013-08-06 at 15:03 +0100, Mark Rutland wrote:
> > On Tue, Aug 06, 2013 at 12:53:10PM +0100, Ivan T. Ivanov wrote:
> > > From: "Ivan T. Ivanov"
> > >
> > > Signed-off-by: Ivan T. Ivanov
> > > ---
> > > .../devicet
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci_hdrc_imx.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index b886998..30fdc2f 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers
At Wed, 07 Aug 2013 23:24:46 +0400,
Бойко Максим wrote:
>
> From: Maksim Boyko
>
> Add the volume control quirk for avoiding the kernel warning for Logitech HD
> Webcam C525.
> The similar patch was previously reported for Logitech HD Webcam C310 (see
> 36691e1be6ec551eef4a5225f126a281f8c051c2
If usb_add_function() fails then the currently processed function
is already not in the list in struct config_usb_cfg, and neither is it
in the list in struct usb_configuration. At the err_purge_funcs label the
purge_config_funcs() is called, which iterates over all configurations,
and in each conf
At Thu, 08 Aug 2013 09:16:27 +0200,
Clemens Ladisch wrote:
>
> Takashi Iwai wrote:
> > Alan Stern wrote:
> >> A buffer _can_ be in the middle of a kmalloc'ed space, but the CPU must
> >> not access any of the fields around it that might occupy the same cache
> >> line while the buffer is being use
Takashi Iwai wrote:
> Alan Stern wrote:
>> A buffer _can_ be in the middle of a kmalloc'ed space, but the CPU must
>> not access any of the fields around it that might occupy the same cache
>> line while the buffer is being used for DMA.
>
> Hrm, but does the kmalloc buffer always guarantee such ca
80 matches
Mail list logo
