ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB
cancellation support."
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-ring.c | 66
drivers/usb/host/xhci.c | 1 -
drivers/usb/host/xhci.h | 2 --
3 files changed, 30 insertions(+), 39 deletion
ae636747146ea97efa18e04576acd3416e2514f5 USB: xhci: URB
cancellation support.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/host/xhci-ring.c | 66
drivers/usb/host/xhci.c | 1 -
drivers/usb/host/xhci.h | 2 --
3 files changed, 30 insertions(+), 39
-ds1307 does.
Tested on AMD G Series Platform (i2c-piix4 adapter driver).
Signed-off-by: Andreas Werner
---
drivers/rtc/rtc-rx8581.c | 81
1 file changed, 68 insertions(+), 13 deletions(-)
diff --git a/drivers/rtc/rtc-rx8581.c b/drivers/rtc/rtc-rx8581
-ds1307 does.
Tested on AMD G Series Platform (i2c-piix4 adapter driver).
Signed-off-by: Andreas Werner andreas.wer...@men.de
---
drivers/rtc/rtc-rx8581.c | 81
1 file changed, 68 insertions(+), 13 deletions(-)
diff --git a/drivers/rtc/rtc-rx8581.c b
>> ...although, the spec says that it does not wait for the port resets
>> to complete. As far as I can see re-issuing a warm reset and waiting
>> is the only way to guarantee the core times the recovery. Presumably
>> the portstatus debounce in hub_activate() mitigates this, but that
>> 100ms
> Sorry for not getting back to this sooner. Ironically, it looks like
> this change isn't needed any more, thanks to Thomas Pugliese's patch:
>
> http://marc.info/?l=linux-usb=13866180520=2
Yes... thanks for pointing it out, that would make this patch
obsolete. I'll wait a few days
> I don't know what you mean by "fails". The system goes to sleep and
> then later on wakes up, doesn't it?
>
> Do you mean that the Jetflash device gets disconnected when the system
> wakes up? That's _supposed_ to happen under those circumstances.
> When hub_activate() sees HUB_RESET_RESUME,
I don't know what you mean by fails. The system goes to sleep and
then later on wakes up, doesn't it?
Do you mean that the Jetflash device gets disconnected when the system
wakes up? That's _supposed_ to happen under those circumstances.
When hub_activate() sees HUB_RESET_RESUME, all child
Sorry for not getting back to this sooner. Ironically, it looks like
this change isn't needed any more, thanks to Thomas Pugliese's patch:
http://marc.info/?l=linux-usbm=13866180520w=2
Yes... thanks for pointing it out, that would make this patch
obsolete. I'll wait a few days
...although, the spec says that it does not wait for the port resets
to complete. As far as I can see re-issuing a warm reset and waiting
is the only way to guarantee the core times the recovery. Presumably
the portstatus debounce in hub_activate() mitigates this, but that
100ms is less
On Tue, Dec 10, 2013 at 2:55 AM, Vivek Gautam wrote:
> The DWC3-exynos eXtensible host controller on Exynos5420 SoC
> is quirky in a way that the PHY needs to be tuned to get it
> working at SuperSpeed.
> By default this PHY works as High-speed phy and therefore
> detects even Super-speed devices
On Tue, Dec 10, 2013 at 2:55 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
The DWC3-exynos eXtensible host controller on Exynos5420 SoC
is quirky in a way that the PHY needs to be tuned to get it
working at SuperSpeed.
By default this PHY works as High-speed phy and therefore
detects even
ice can always be marked as
unconfigured (reclaiming its bandwidth) in the kernel, regardless of
communication problems. This patch changes usb_set_configuration() to
ignore all failures in the case where no new configuration is being set.
Signed-off-by: Julius Werner
---
drivers/usb/core/messag
can always be marked as
unconfigured (reclaiming its bandwidth) in the kernel, regardless of
communication problems. This patch changes usb_set_configuration() to
ignore all failures in the case where no new configuration is being set.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers
> Instead, how about changing usb_set_configuration() so that it will
> never fail when the new config is -1? Except perhaps for -ENODEV
> errors (the device has been disconnected), which
> usb_deauthorize_device() could check for.
Yes, that should work as well. It's really just one autoresume
Instead, how about changing usb_set_configuration() so that it will
never fail when the new config is -1? Except perhaps for -ENODEV
errors (the device has been disconnected), which
usb_deauthorize_device() could check for.
Yes, that should work as well. It's really just one autoresume and
res that usb_deauthorize_device() aborts when
usb_set_configuration() fails, and the underlying status code (such as
ENODEV) is returned to userspace.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/driv
that usb_deauthorize_device() aborts when
usb_set_configuration() fails, and the underlying status code (such as
ENODEV) is returned to userspace.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/hub.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/usb
*ping*
Is anyone still reading this or should I resubmit? Sorry for being
annoying, just please let me know if this is already considered to get
picked up at the next opportunity or if you've intentionally decided
against it for now. I want to make sure it didn't fall through the
cracks
*ping*
Is anyone still reading this or should I resubmit? Sorry for being
annoying, just please let me know if this is already considered to get
picked up at the next opportunity or if you've intentionally decided
against it for now. I want to make sure it didn't fall through the
cracks
I'm not sure if it's worth it further looking into this for the
SUSPENDED state (Sarah's post sounds like that shouldn't happen)...
but at any rate, that would be orthogonal to my patch, right? I'm
really only interested in the NOTATTACHED case, which solves a real
issue on my system. Do you still
I'm not sure if it's worth it further looking into this for the
SUSPENDED state (Sarah's post sounds like that shouldn't happen)...
but at any rate, that would be orthogonal to my patch, right? I'm
really only interested in the NOTATTACHED case, which solves a real
issue on my system. Do you still
the function and add the
read to pch_i2c_wait_for_check_xfer.
If no ACK is received, the Message will be printed as a dbg
message.
Fixed print message to be a one liner so we can grep for the
error message.
Tested on Intel Atom E6xx and Eg20t Chipset.
Signed-off-by: Andreas Werner
---
Revision 2
On Sun, Nov 17, 2013 at 06:08:38PM +0100, Wolfram Sang wrote:
> On Sun, Nov 17, 2013 at 05:53:29PM +0100, Andreas Werner wrote:
> > On Sun, Nov 17, 2013 at 01:18:09PM +0100, Wolfram Sang wrote:
> > >
> > > > Is there another reason why pch_i2c_getack returne
On Sun, Nov 17, 2013 at 01:18:09PM +0100, Wolfram Sang wrote:
>
> > Is there another reason why pch_i2c_getack returned EPROTO?
> > May be ENXIO was introduced later?
>
> Imperfect review :)
>
> > I think we can just replace the -EIO with -ENXIO or do you want to pick up
> > the return
> >
On Sun, Nov 17, 2013 at 12:08:46PM +0100, Wolfram Sang wrote:
> On Sun, Nov 17, 2013 at 09:58:51AM +0100, Andreas Werner wrote:
> > Revision 2:
> > - delete the pch_err completly instead of changing to pch_dbg
> > because there is already a pch_dbg at t
On Sun, Nov 17, 2013 at 12:08:46PM +0100, Wolfram Sang wrote:
On Sun, Nov 17, 2013 at 09:58:51AM +0100, Andreas Werner wrote:
Revision 2:
- delete the pch_err completly instead of changing to pch_dbg
because there is already a pch_dbg at the function who calls
On Sun, Nov 17, 2013 at 01:18:09PM +0100, Wolfram Sang wrote:
Is there another reason why pch_i2c_getack returned EPROTO?
May be ENXIO was introduced later?
Imperfect review :)
I think we can just replace the -EIO with -ENXIO or do you want to pick up
the return
vale of
On Sun, Nov 17, 2013 at 06:08:38PM +0100, Wolfram Sang wrote:
On Sun, Nov 17, 2013 at 05:53:29PM +0100, Andreas Werner wrote:
On Sun, Nov 17, 2013 at 01:18:09PM +0100, Wolfram Sang wrote:
Is there another reason why pch_i2c_getack returned EPROTO?
May be ENXIO was introduced later
the function and add the
read to pch_i2c_wait_for_check_xfer.
If no ACK is received, the Message will be printed as a dbg
message.
Fixed print message to be a one liner so we can grep for the
error message.
Tested on Intel Atom E6xx and Eg20t Chipset.
Signed-off-by: Andreas Werner wernera...@gmx.de
On Thu, Nov 14, 2013 at 08:57:58PM +, One Thousand Gnomes wrote:
> > but if you checkout the PCI table in the driver, there is the device
> > and vendor ID mentioned, that means for me that the driver supports
> > the Graphic core in E680.
> > And after loading the driver, it will parse for
On Thu, Nov 14, 2013 at 08:57:58PM +, One Thousand Gnomes wrote:
but if you checkout the PCI table in the driver, there is the device
and vendor ID mentioned, that means for me that the driver supports
the Graphic core in E680.
And after loading the driver, it will parse for $VBT.
I
On Thu, Nov 14, 2013 at 05:39:52AM -0800, Joe Perches wrote:
> On Wed, 2013-11-13 at 20:24 +0100, Marek Vasut wrote:
> > > On Tue, Nov 12, 2013 at 07:33:40PM +0100, Marek Vasut wrote:
> > > > > > That is because if you look at the only caller of this function,
> > > > > > which is
On Thu, Nov 14, 2013 at 01:52:09PM +, One Thousand Gnomes wrote:
> > My question now is, is it a bug in the driver or in the VGA Bios?
> >
> > I´ve checked the VGA bios and did a hex dump but there is really no "$VBT"
> > string.
> > On an Atom Gen1 CPU with intel GMA500 Graphic there is the
On Thu, Nov 14, 2013 at 01:52:09PM +, One Thousand Gnomes wrote:
My question now is, is it a bug in the driver or in the VGA Bios?
I´ve checked the VGA bios and did a hex dump but there is really no $VBT
string.
On an Atom Gen1 CPU with intel GMA500 Graphic there is the string in
On Thu, Nov 14, 2013 at 05:39:52AM -0800, Joe Perches wrote:
On Wed, 2013-11-13 at 20:24 +0100, Marek Vasut wrote:
On Tue, Nov 12, 2013 at 07:33:40PM +0100, Marek Vasut wrote:
That is because if you look at the only caller of this function,
which is pch_i2c_wait_for_check_xfer(),
I´ve a question about the GMA 500 driver (gma500_gfx) with an Intel Atom E680.
Since the gma500 driver is in the Kernel, i get a black screen after loading
the driver.
The last message i can see are "Invalid VBT signature".
I have check the driver file "intel_bios.c" and there the driver map
the
On Tue, Nov 12, 2013 at 07:33:40PM +0100, Marek Vasut wrote:
> Dear Andreas Werner,
>
> > On Tue, Nov 12, 2013 at 07:00:59PM +0100, Marek Vasut wrote:
> > > Dear Andreas Werner,
> > >
> > > > Using the i2c-eg20t driver and call i2cdetect or probe on th
On Tue, Nov 12, 2013 at 07:33:40PM +0100, Marek Vasut wrote:
Dear Andreas Werner,
On Tue, Nov 12, 2013 at 07:00:59PM +0100, Marek Vasut wrote:
Dear Andreas Werner,
Using the i2c-eg20t driver and call i2cdetect or probe on the bus,
the driver will print a lot of error messages
I´ve a question about the GMA 500 driver (gma500_gfx) with an Intel Atom E680.
Since the gma500 driver is in the Kernel, i get a black screen after loading
the driver.
The last message i can see are Invalid VBT signature.
I have check the driver file intel_bios.c and there the driver map
the
On Tue, Nov 12, 2013 at 07:00:59PM +0100, Marek Vasut wrote:
> Dear Andreas Werner,
>
> > Using the i2c-eg20t driver and call i2cdetect or probe on the bus,
> > the driver will print a lot of error messages if there was no ACK
> > received.
> >
> > i2cde
-eg20t driver, the table is not visible because
the error messages destroy the table.
Error message: pch_i2c_getack return -71
This patch prevent the driver to print the messages to syslog if debug is not
set.
Tested on Intel Atom E6xx and Eg20t Chipset.
Signed-off-by: Andreas Werner
---
drivers
-eg20t driver, the table is not visible because
the error messages destroy the table.
Error message: pch_i2c_getack return -71
This patch prevent the driver to print the messages to syslog if debug is not
set.
Tested on Intel Atom E6xx and Eg20t Chipset.
Signed-off-by: Andreas Werner wernera
On Tue, Nov 12, 2013 at 07:00:59PM +0100, Marek Vasut wrote:
Dear Andreas Werner,
Using the i2c-eg20t driver and call i2cdetect or probe on the bus,
the driver will print a lot of error messages if there was no ACK
received.
i2cdetect normally print a table with all the available
the port broken.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index e6b682c..0188056 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4799,8 +4799,9
> I don't know either. But Sarah has said that ports can spontaneously
> go into Compliance Mode for no apparent reason. If that can happen,
> maybe it can happen while the port is in U3 and the device is
> suspended. In such cases, though, you'd need to do a reset-resume
> rather than a simple
I don't know either. But Sarah has said that ports can spontaneously
go into Compliance Mode for no apparent reason. If that can happen,
maybe it can happen while the port is in U3 and the device is
suspended. In such cases, though, you'd need to do a reset-resume
rather than a simple
the port broken.
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/hub.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index e6b682c..0188056 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
> Who makes those calls, drivers? Any specific ones that you know need to
be fixed?
Well, the one I'm worried about is the one this patch is fixing, in
hub_events(). I have seen this happen when having certain USB3 devices
plugged into a host controller that always looses power on
suspend-to-ram
*bump*
Hi Sarah, is there anything else that needs to be resolved to pick
this patch up? Looks like Matthias' recent LPM fixes are all in now so
there should be no way this could cause any trouble?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
the port broken.
Also bumped the messages about this kind of reset failure from dev_dbg()
to dev_warn() to make it easier to notice, since calling that function
with a NOTATTACHED device would almost always be a bug
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 9 +
1 file changed
the port broken.
Also bumped the messages about this kind of reset failure from dev_dbg()
to dev_warn() to make it easier to notice, since calling that function
with a NOTATTACHED device would almost always be a bug
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/hub.c | 9
*bump*
Hi Sarah, is there anything else that needs to be resolved to pick
this patch up? Looks like Matthias' recent LPM fixes are all in now so
there should be no way this could cause any trouble?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Who makes those calls, drivers? Any specific ones that you know need to
be fixed?
Well, the one I'm worried about is the one this patch is fixing, in
hub_events(). I have seen this happen when having certain USB3 devices
plugged into a host controller that always looses power on
suspend-to-ram
On Sun, Nov 03, 2013 at 09:44:46AM -0800, H. Peter Anvin wrote:
> On 11/03/2013 04:02 AM, Andreas Werner wrote:
> >
> > Since marking IO Memory as cachable is not valid, WT is the
> > best way for caching/bursting on MMIO Devices.
> >
>
> Uh... WT *is* cachabl
following combination:
PAT=Write-Back + MTRR=Write-Through.
Since marking IO Memory as cachable is not valid, WT is the
best way for caching/bursting on MMIO Devices.
Tested on - Intel (R) Atom E680 (Tunnel Creek)
- Intel (R) Core(TM)2 Duo
Signed-off-by: Andreas Werner
---
arch/x86/mm/
combination:
PAT=Write-Back + MTRR=Write-Through.
Since marking IO Memory as cachable is not valid, WT is the
best way for caching/bursting on MMIO Devices.
Tested on - Intel (R) Atom E680 (Tunnel Creek)
- Intel (R) Core(TM)2 Duo
Signed-off-by: Andreas Werner wernera...@gmx.de
---
arch/x86
On Sun, Nov 03, 2013 at 09:44:46AM -0800, H. Peter Anvin wrote:
On 11/03/2013 04:02 AM, Andreas Werner wrote:
Since marking IO Memory as cachable is not valid, WT is the
best way for caching/bursting on MMIO Devices.
Uh... WT *is* cachable...
-hpa
Sorry my mistake, i
On Mon, Oct 28, 2013 at 02:58:47PM +0100, Borislav Petkov wrote:
> On Mon, Oct 28, 2013 at 01:03:58PM +0100, Andreas Werner wrote:
> > > That doesn't mean you can return _PAGE_CACHE_WB for MTRR_TYPE_WRTHROUGH.
> > > The correct thing to do, IMHO, would be to set th
On Mon, Oct 28, 2013 at 12:45:41PM +0100, Borislav Petkov wrote:
> Drop Dave's stale mail address.
>
> On Mon, Oct 28, 2013 at 12:25:05PM +0100, Andreas Werner wrote:
> > > but you end up doing
> > >
> > > PAT=Write-Back + MTRR=Write-Thro
On Mon, Oct 28, 2013 at 11:57:31AM +0100, Borislav Petkov wrote:
> On Mon, Oct 28, 2013 at 11:34:28AM +0100, Andreas Werner wrote:
> > Yes the reads are only for packet data, the commands or configuration
> > registers are mapped non cachable.
> >
> > I´ve tried WB,
On Mon, Oct 28, 2013 at 11:51:01AM +0100, Ingo Molnar wrote:
>
> * Andreas Werner wrote:
>
> > On Mon, Oct 28, 2013 at 11:31:32AM +0100, Ingo Molnar wrote:
> > >
> > > * Borislav Petkov wrote:
> > >
> > > > On Mo
On Mon, Oct 28, 2013 at 11:31:32AM +0100, Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > On Mon, Oct 28, 2013 at 11:17:49AM +0100, Ingo Molnar wrote:
> >
> > > And regular write-back cacheable isn't sufficient because the
> > > CPU could do things like prefetch your range automatically?
On Mon, Oct 28, 2013 at 11:17:49AM +0100, Ingo Molnar wrote:
>
> * Andreas Werner wrote:
>
> > > IOW, you probably could use a WC buffer here too, as it would
> > > combine the writes coming from the FPGA.
> > >
> > > Btw, there's also mtrr_add(.
On Sun, Oct 27, 2013 at 08:01:48PM +0100, Borislav Petkov wrote:
> On Sun, Oct 27, 2013 at 06:56:08PM +0100, Andreas Werner wrote:
> > Transmit Buffers WC (only write to that buffer)
> > i have PICe bursts on my tracer.
>
> For that you can do ioremap_wc().
Yes i am curre
On Sun, Oct 27, 2013 at 08:01:48PM +0100, Borislav Petkov wrote:
On Sun, Oct 27, 2013 at 06:56:08PM +0100, Andreas Werner wrote:
Transmit Buffers WC (only write to that buffer)
i have PICe bursts on my tracer.
For that you can do ioremap_wc().
Yes i am currently using ioremap_wc
On Mon, Oct 28, 2013 at 11:17:49AM +0100, Ingo Molnar wrote:
* Andreas Werner wernera...@gmx.de wrote:
IOW, you probably could use a WC buffer here too, as it would
combine the writes coming from the FPGA.
Btw, there's also mtrr_add(..., MTRR_TYPE_WRTHROUGH, ) if you
must
On Mon, Oct 28, 2013 at 11:31:32AM +0100, Ingo Molnar wrote:
* Borislav Petkov b...@alien8.de wrote:
On Mon, Oct 28, 2013 at 11:17:49AM +0100, Ingo Molnar wrote:
And regular write-back cacheable isn't sufficient because the
CPU could do things like prefetch your range
On Mon, Oct 28, 2013 at 11:51:01AM +0100, Ingo Molnar wrote:
* Andreas Werner wernera...@gmx.de wrote:
On Mon, Oct 28, 2013 at 11:31:32AM +0100, Ingo Molnar wrote:
* Borislav Petkov b...@alien8.de wrote:
On Mon, Oct 28, 2013 at 11:17:49AM +0100, Ingo Molnar wrote
On Mon, Oct 28, 2013 at 11:57:31AM +0100, Borislav Petkov wrote:
On Mon, Oct 28, 2013 at 11:34:28AM +0100, Andreas Werner wrote:
Yes the reads are only for packet data, the commands or configuration
registers are mapped non cachable.
I´ve tried WB, but on PCIe Tracer i could not see any
On Mon, Oct 28, 2013 at 12:45:41PM +0100, Borislav Petkov wrote:
Drop Dave's stale mail address.
On Mon, Oct 28, 2013 at 12:25:05PM +0100, Andreas Werner wrote:
but you end up doing
PAT=Write-Back + MTRR=Write-Through = Effective Memory of Write-Back
No the effective memory
On Mon, Oct 28, 2013 at 02:58:47PM +0100, Borislav Petkov wrote:
On Mon, Oct 28, 2013 at 01:03:58PM +0100, Andreas Werner wrote:
That doesn't mean you can return _PAGE_CACHE_WB for MTRR_TYPE_WRTHROUGH.
The correct thing to do, IMHO, would be to set the PWT bit in the PTEs
of those pages
On Sun, Oct 27, 2013 at 06:31:31PM +0100, Borislav Petkov wrote:
> On Sun, Oct 27, 2013 at 05:51:59PM +0100, Andreas Werner wrote:
> > Im currently working on an ethernet driver for our own ETH core. The
> > problem is that one requirement is to not use DMA to transmit or
>
On Sun, Oct 27, 2013 at 02:34:01PM +0100, Borislav Petkov wrote:
> On Sun, Oct 27, 2013 at 01:55:25PM +0100, Andreas Werner wrote:
> > This patch adds the Write-through memory type in combination with mtrr.
> > If you call ioremap_cache to request cachable memory (write-back) t
MTRR=Write-Through = Effective Memory of
Write-Through
Tested on - Intel (R) Atom E680 (Tunnel Creek)
- Intel (R) Core(TM)2 Duo
Signed-off-by: Andreas Werner
---
arch/x86/mm/pat.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/p
= Effective Memory of
Write-Through
Tested on - Intel (R) Atom E680 (Tunnel Creek)
- Intel (R) Core(TM)2 Duo
Signed-off-by: Andreas Werner wernera...@gmx.de
---
arch/x86/mm/pat.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86
On Sun, Oct 27, 2013 at 02:34:01PM +0100, Borislav Petkov wrote:
On Sun, Oct 27, 2013 at 01:55:25PM +0100, Andreas Werner wrote:
This patch adds the Write-through memory type in combination with mtrr.
If you call ioremap_cache to request cachable memory (write-back) the
function tries
On Sun, Oct 27, 2013 at 06:31:31PM +0100, Borislav Petkov wrote:
On Sun, Oct 27, 2013 at 05:51:59PM +0100, Andreas Werner wrote:
Im currently working on an ethernet driver for our own ETH core. The
problem is that one requirement is to not use DMA to transmit or
receive the data. This means
> Did you run into an issue where port status change events weren't being
> generated because the Port Reset flag was set? I'm trying to figure out
> if this addresses a real issue you hit (and thus should be queued for
> stable), or if this is just a precaution.
As Benson said, we're seeing
Did you run into an issue where port status change events weren't being
generated because the Port Reset flag was set? I'm trying to figure out
if this addresses a real issue you hit (and thus should be queued for
stable), or if this is just a precaution.
As Benson said, we're seeing this on
. This is especially dangerous for XHCI root hubs, which don't
generate any more Port Status Change Events until all change bits are
cleared, so this is a good precaution to have (similar to how it's
already done for the Warm Port Reset Change flag).
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c
>> + if ((portchange & USB_PORT_STAT_C_RESET)) {
>
>
>Hm, why these double parens?
Oh... good question. I copied the entry below it, remove the && and
must have overlooked those. Sorry, v2 incoming...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
. This is especially dangerous for XHCI root hubs, which don't
generate any more Port Status Change Events until all change bits are
cleared, so this is a good precaution to have (similar to how it's
already done for the Warm Port Reset Change flag).
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c
+ if ((portchange USB_PORT_STAT_C_RESET)) {
Hm, why these double parens?
Oh... good question. I copied the entry below it, remove the and
must have overlooked those. Sorry, v2 incoming...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
. This is especially dangerous for XHCI root hubs, which don't
generate any more Port Status Change Events until all change bits are
cleared, so this is a good precaution to have (similar to how it's
already done for the Warm Port Reset Change flag).
Signed-off-by: Julius Werner jwer...@chromium.org
. This is especially dangerous for XHCI root hubs, which don't
generate any more Port Status Change Events until all change bits are
cleared, so this is a good precaution to have (similar to how it's
already done for the Warm Port Reset Change flag).
Signed-off-by: Julius Werner jwer...@chromium.org
> If you take a look at Table
> 13: BESL/HIRD Encoding from the xHCI spec version including errata to
> 08/14/2012
Could you please provide a link to that errata? I still cannot find
it... but from your explanation, that design decision sounds pretty
horrible. Why didn't they just choose not to
If you take a look at Table
13: BESL/HIRD Encoding from the xHCI spec version including errata to
08/14/2012
Could you please provide a link to that errata? I still cannot find
it... but from your explanation, that design decision sounds pretty
horrible. Why didn't they just choose not to set
> So the 2.41a has BESL support, but may not set the BLC flag. What
> happens if we use the HIRD encoding instead? Will things break? It
> seems like we would need to disable USB 2.0 LPM on that host all
> together, if it expects BESL encoding, but advertises HIRD encoding.
Wait a second, just
I've tried to get the 3503 driver to work in my case for quite some
time, but ultimately gave up. For me, playing around with the load
order was not enough to solve all issues. When you try to build a
permanent, clean solution for this, you should definitely also test
the case where the hub has
I've tried to get the 3503 driver to work in my case for quite some
time, but ultimately gave up. For me, playing around with the load
order was not enough to solve all issues. When you try to build a
permanent, clean solution for this, you should definitely also test
the case where the hub has
So the 2.41a has BESL support, but may not set the BLC flag. What
happens if we use the HIRD encoding instead? Will things break? It
seems like we would need to disable USB 2.0 LPM on that host all
together, if it expects BESL encoding, but advertises HIRD encoding.
Wait a second, just for
*Ping!*
Are there still unanswered concerns left with this patch? I hope my
prior mails could clear up why I think that the PMU register
description in the device tree for a specific PHY is represents the
hardware more accurately after my patch, and my analysis of the
Exynos4 situation currently
*Ping!*
Are there still unanswered concerns left with this patch? I hope my
prior mails could clear up why I think that the PMU register
description in the device tree for a specific PHY is represents the
hardware more accurately after my patch, and my analysis of the
Exynos4 situation currently
MTRR=Write-Through = Effective Memory of Write-Through
Tested on - Intel (R) Atom E680 (Tunnel Creek)
- Intel (R) Core(TM)2 Duo
Signed-off-by: Andreas Werner
---
arch/x86/mm/pat.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x8
-Through = Effective Memory of Write-Through
Tested on - Intel (R) Atom E680 (Tunnel Creek)
- Intel (R) Core(TM)2 Duo
Signed-off-by: Andreas Werner wernera...@gmx.de
---
arch/x86/mm/pat.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch
With compiling and using this, have too much problems
/ In wil6210 some problem with call arguments ; that
messes the whole compilation of the kernel because gives
an error condition
/ ibmphpd :something run-time-wrong
/ in the second compilation stage, plenty modules or
> On Fri, Aug 23, 2013 at 11:18 AM, Andreas Werner
> wrote:
>> Hi,
>>
>> why are you curious?
>>
>> I have never heard about movntdqa. Have you ever tried it?
>> May be it is a good idea to try i out.
>
> I've never tried it, but in theory
Hi,
why are you curious?
I have never heard about movntdqa. Have you ever tried it?
May be it is a good idea to try i out.
I think i will commit the patch to the kernel and see what happens :-)
Best regards.
>> On Fri, Aug 23, 2013 at 9:59 AM, Andreas Werner
>> wrote:
&g
Hi,
why are you curious?
I have never heard about movntdqa. Have you ever tried it?
May be it is a good idea to try i out.
I think i will commit the patch to the kernel and see what happens :-)
Best regards.
>> On Fri, Aug 23, 2013 at 9:59 AM, Andreas Werner
>> wrote:
&g
501 - 600 of 1003 matches
Mail list logo
