Arnd Bergmann writes:
> On Tuesday, September 6, 2016 1:50:48 PM CEST Felipe Balbi wrote:
>> Hi,
>>
>> Arnd Bergmann writes:
>> > On Tuesday, September 6, 2016 9:40:19 AM CEST Felipe Balbi wrote:
>> >>
>> >> this only solves the problem for DT devices. Legacy devices and
>> >> PCI-based system
On 07.09.2016 09:22, Lu Baolu wrote:
From: "Lu, Baolu"
xhci_setup_device() should return failure with correct error number
when xhci host has died, removed or halted.
Thanks, will add.
Might go to 4.9 as 4.8-rc5 is already out
-Mathias
--
To unsubscribe from this list: send the line "unsubs
On Tue, Sep 06, 2016 at 12:38:29PM +0200, Arnd Bergmann wrote:
> On Tuesday, September 6, 2016 2:35:29 PM CEST Peter Chen wrote:
> > On Mon, Sep 05, 2016 at 05:39:27PM +0200, Arnd Bergmann wrote:
> > > On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote:
>
> > >
> > > Most of these are prob
From: "Lu, Baolu"
xhci_setup_device() should return failure with correct error number
when xhci host has died, removed or halted.
Cc: sta...@vger.kernel.org # 4.3+
Signed-off-by: Lu Baolu
---
drivers/usb/host/xhci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers
Commit 50c763f8c1bac ("usb: dwc3: Set the ClearPendIN bit on Clear
Stall EP command") causes Clear Stall EP command failure on Intel
Cherry Trail devices. This patch add a quirk to avoid setting this
bit for those Intel devices.
Cc: sta...@vger.kernel.org # 4.7+
Signed-off-by: Lu Baolu
---
drive
From: Thinh Nguyen
This patch follows the similar fix in dwc2. See
commit 5268ed9d2e3b ("usb: dwc2: Fix dr_mode validation")
Currently, the dr_mode is only checked against the module configuration.
It also needs to be checked against the hardware capablities.
The driver now checks if both the m
On Wed, 2016-09-07 at 02:00 +, ronnie.ku...@microchip.com wrote:
> Microchip's internal convention is for register (offset) definitions
> to be capitalized (i.e.: MY_REGISTER). Our convention for bits
> (position) definitions within a register is to carry as a prefix the
> name of the register
On 9/6/2016 6:19 PM, Ayaka wrote:
>
>
> 從我的 iPad 傳送
>
>> John Youn 於 2016年9月7日 上午2:54 寫道：
>>
>>> On 9/5/2016 10:15 PM, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
On Sunday 04 September 2016 03:25 AM, Randy Li wrote:
On the rk3288 USB host-only port (the one that's not the OTG-enabled
>
Microchip's internal convention is for register (offset) definitions to be
capitalized (i.e.: MY_REGISTER). Our convention for bits (position) definitions
within a register is to carry as a prefix the name of the register and suffix
it with the bit name and adding a trailing underscore (i.e.
MY
On Tue, 2016-09-06 at 23:19 +, woojung@microchip.com wrote:
> > Joe Perches (2):
> > lan78xx: Remove locally defined trailing underscores from defines and uses
> > microchipphy.h and uses: Remove trailing underscores from defines and
> > uses
> >
> > drivers/net/phy/microchip.c |
從我的 iPad 傳送
> John Youn 於 2016年9月7日 上午2:54 寫道：
>
>> On 9/5/2016 10:15 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>>> On Sunday 04 September 2016 03:25 AM, Randy Li wrote:
>>> On the rk3288 USB host-only port (the one that's not the OTG-enabled
>>> port) the PHY can get into a bad state when
On 09/04, Martin Blumenstingl wrote:
> USB0_DDR_BRIDGE and USB1_DDR_BRIDGE1 are needed for the related
> dwc2 usb controller. USB, USB0 and USB1 are needed for the PHYs.
> Expose these clocks to DT and comment out in clk driver.
>
> Signed-off-by: Jerome Brunet
> Signed-off-by: Martin Blumensting
> Joe Perches (2):
> lan78xx: Remove locally defined trailing underscores from defines and uses
> microchipphy.h and uses: Remove trailing underscores from defines and
> uses
>
> drivers/net/phy/microchip.c |4 +-
> drivers/net/usb/lan78xx.c| 368 +++
> drivers/net/usb/l
Macro defines with trailing underscore are hard to read.
These locally defined ones with trailing underscores are all unique
without the trailing underscore, so remove them from the defines and uses.
Global defines that start with LAN88XX_ that are excluded.
Done with:
$ perl -p -i -e 's/\b(?!L
Joe Perches (2):
lan78xx: Remove locally defined trailing underscores from defines and uses
microchipphy.h and uses: Remove trailing underscores from defines and uses
drivers/net/phy/microchip.c |4 +-
drivers/net/usb/lan78xx.c| 368 +++
drivers/net/usb/lan78xx.h| 10
Macro defines with trailing underscore are hard to read.
These uses with trailing underscores are all unique to this .h file,
so remove them from the defines and uses.
Done with:
$ sed -r -i -e 's/\b([A-Z0-9_][A-Za-z0-9_]+)_\b/\U\1\E/g' \
include/linux/microchipphy.h \
drivers/net/usb/lan78x
From: Baoyou Xie
Date: Tue, 6 Sep 2016 16:19:02 +0800
> We get a few warnings when building kernel with W=1:
> drivers/net/usb/lan78xx.c:1182:6: warning: no previous prototype for
> 'lan78xx_defer_kevent' [-Wmissing-prototypes]
> drivers/net/usb/lan78xx.c:1409:5: warning: no previous prototype
On 2016-09-06 12:41 PM, Grant Grundler wrote:
On Thu, Sep 1, 2016 at 10:02 AM, Eric Dumazet wrote:
On Thu, 2016-09-01 at 12:47 -0400, Robert Foss wrote:
I'm not quite sure how the first From line was added, it
should not have been.
Grant Grundler is most definitely the author.
Would you li
Hi John,
> John Youn hat am 1. September 2016 um 23:07
> geschrieben:
>
>
> This series accounts for the delay from the IDDIG debounce filter when
> switching modes. This delay is a function of the PHY clock speed and
> can range from 5-50 ms. This delay must be taken into account on core
> res
Make the #defines a bit more sensible to read.
Done with:
$ sed -r -i -e 's/\b([A-Z0-9_][A-Za-z0-9_]+)_\b/\U\1\E/g' \
drivers/net/usb/smsc95xx.[ch]
and a little editing of the .h file to realign tabstop define values.
There are 3 [RT]x_COE_ defines that were also uppercased.
No change in def
From: Joe Perches
Date: Fri, 2 Sep 2016 15:58:00 -0700
> This seems to be the only code in the kernel that uses
> macro defines with a trailing underscore. Fix that.
Series applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majo
Hi Greg and Alan,
On Mon, Sep 05, 2016 at 03:00:30PM -0500, David Lechner wrote:
> Just resending to get these merged into usb. The phy parts of this patch
> series
> have already been merged into Linus' tree.
>
> I have rebased on 4.8-rc5 but there have not been any changes to these since
> the
Hi,
On Mon, Sep 05, 2016 at 03:00:32PM -0500, David Lechner wrote:
> Simplify things a bit by using devm functions where possible.
>
> Signed-off-by: David Lechner
> ---
> drivers/usb/musb/da8xx.c | 19 +--
> 1 file changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/dri
On 9/5/2016 10:15 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Sunday 04 September 2016 03:25 AM, Randy Li wrote:
>> On the rk3288 USB host-only port (the one that's not the OTG-enabled
>> port) the PHY can get into a bad state when a wakeup is asserted (not
>> just a wakeup from full system sus
On 2016-09-06 01:22, Mark Brown wrote:
> On Tue, Sep 06, 2016 at 10:45:19AM +0300, Felipe Balbi wrote:
>> Stefan Agner writes:
>
>> > According to the device tree bindings the vcc-supply is optional.
>
> This is nonsense unless the device can work without this supply. Given
> that the supply is
On Sun, Sep 4, 2016 at 7:39 PM, Peter Chen wrote:
> On Fri, Sep 02, 2016 at 06:03:06PM -0700, Stephen Boyd wrote:
>> On Thu, Sep 1, 2016 at 8:17 PM, Peter Chen wrote:
>> > On Wed, Aug 31, 2016 at 05:40:24PM -0700, Stephen Boyd wrote:
>> >>
>> >>
>> >> if (cable->state)
>> >> -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello Ulf,
On Tue, 2016-09-06 at 11:42 +0200, Ulf Hansson wrote:
>
> By reviewing the code of the rtsx_usb_sdmmc driver, particularly how
> it calls pm_runtime_get|put() I am guessing those calls may not be
> properly deployed. Perhaps rtsx_usb_sdm
On Thu, Sep 1, 2016 at 10:02 AM, Eric Dumazet wrote:
> On Thu, 2016-09-01 at 12:47 -0400, Robert Foss wrote:
>
>> I'm not quite sure how the first From line was added, it
>> should not have been.
>> Grant Grundler is most definitely the author.
>>
>> Would you like me to resubmit in v++ and make s
Apply for a loan at 2% reply to this Email for more Info
--
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
On Tue, Sep 06, 2016 at 10:46:55AM -0400, Alan Stern wrote:
Not knowing where INFO() goes, you should use trace_printk() not
printk(), as the former is strictly per cpu, while the latter is
globally serialized and can hide all these problems.
> Index: usb-4.x/drivers/usb/gadget/function/f_mass_st
On Tue, 6 Sep 2016, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 01:49:37PM +0200, Peter Zijlstra wrote:
> > On Tue, Sep 06, 2016 at 02:43:39PM +0300, Felipe Balbi wrote:
>
> > > My fear now, however, is that changing smp_[rw]mb() to smp_mb() just
> > > adds extra overhead which makes the prob
On 29.08.2016 10:26, Srinath Mannam wrote:
Hi Mathias Nyman,
Could you please provide your inputs on this?
If you find it in good condition, please consider it for the next release.
I'm not that involved in the usb phy or generic phy, but to me it looks like
we should let usb core handle this
On Tuesday, September 6, 2016 1:50:48 PM CEST Felipe Balbi wrote:
> Hi,
>
> Arnd Bergmann writes:
> > On Tuesday, September 6, 2016 9:40:19 AM CEST Felipe Balbi wrote:
> >>
> >> this only solves the problem for DT devices. Legacy devices and
> >> PCI-based systems will still suffer from the same
Starting with v4.8-rc5, we get a warning about the dwc3_pci_pm_dummy function
when CONFIG_PM_SLEEP is disabled:
drivers/usb/dwc3/dwc3-pci.c:253:12: warning: 'dwc3_pci_pm_dummy' defined but
not used
Using __maybe_unused instead of #ifdef lets the compiler figure out
whether it should drop the def
On Tue, Sep 06, 2016 at 01:49:37PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 02:43:39PM +0300, Felipe Balbi wrote:
> > My fear now, however, is that changing smp_[rw]mb() to smp_mb() just
> > adds extra overhead which makes the problem much, much less likely to
> > happen. Does that s
On Tue, Sep 06, 2016 at 02:43:39PM +0300, Felipe Balbi wrote:
> > Could you confirm that bulk_{in,out}_complete() work on different
> > usb_request structures, and they can not, at any time, get called on the
> > _same_ request?
>
> usb_requests are allocated for a specific endpoint and USB Devic
Hi,
Peter Zijlstra writes:
> On Mon, Sep 05, 2016 at 11:29:26AM -0400, Alan Stern wrote:
>> On Mon, 5 Sep 2016, Peter Zijlstra wrote:
>>
>> > > Actually, seeing it written out like this, one realizes that it really
>> > > ought to be:
>> > >
>> > > CPU 0 CPU 1
>> >
On Mon, Sep 05, 2016 at 11:29:26AM -0400, Alan Stern wrote:
> On Mon, 5 Sep 2016, Peter Zijlstra wrote:
>
> > > Actually, seeing it written out like this, one realizes that it really
> > > ought to be:
> > >
> > > CPU 0 CPU 1
> > > -
On Mon, Sep 05, 2016 at 10:43:11AM +0100, Will Deacon wrote:
> On Sat, Sep 03, 2016 at 12:16:29AM +0200, Peter Zijlstra wrote:
> > Forgot to Cc Will. Will, does ARM64 need to make smp_mb__before_spinlock
> > smp_mb() too?
>
> Yes, probably. Just to confirm, the test is something like:
>
>
> CPU
Hi,
Arnd Bergmann writes:
> On Tuesday, September 6, 2016 9:40:19 AM CEST Felipe Balbi wrote:
>>
>> this only solves the problem for DT devices. Legacy devices and
>> PCI-based systems will still suffer from the same problem. At least for
>> dwc3, I will only be taking patches that solve the pr
On Tuesday, September 6, 2016 9:40:19 AM CEST Felipe Balbi wrote:
>
> this only solves the problem for DT devices. Legacy devices and
> PCI-based systems will still suffer from the same problem. At least for
> dwc3, I will only be taking patches that solve the problem for all
> users, not a subset
SUMMARY:
Logitech Precision Gamepad shows axis activity upon connection
DESCRIPTION:
When I connect my Logitech Precision Gamepad (or the machine starts up
with it connected) it exhibits activity on both axes until I press a
button/press the d-pad.
eddie@codey:~$ cat /proc/version
Linux version 4
On Tuesday, September 6, 2016 2:35:29 PM CEST Peter Chen wrote:
> On Mon, Sep 05, 2016 at 05:39:27PM +0200, Arnd Bergmann wrote:
> > On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote:
> >
> > Most of these are probably never used with any nonstandard
> > DMA settings (IOMMU, cache coheren
a
On Friday 02 September 2016 06:40 AM, Peter Chen wrote:
On Wed, Aug 31, 2016 at 10:28:20PM +0530, Vaibhav Hiremath wrote:
On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:
On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:
On Monday 29 August 2016 04:40 PM, Peter Chen
On Tue, 2016-08-30 at 08:14 -0400, Robert Krawitz wrote:
> > This is the typical error handling of UAS, which works in your case,
> > albeit with a performance penalty. But the actual cause of kicking
> in
> > the error handler is missing in your log. You cut too much at the
> > beginning.
>
> Her
Hans Petter Selasky writes:
> On 09/06/16 08:44, Felipe Balbi wrote:
>> Hi,
>>
>> Felipe Balbi writes:
>>> > According to USB 3.1 Specification, that field is 2
>>> > bytes wide and is named with a 'w' prefix, not 'b'.
>>> >
>>> > Just to make grepping in the spec easier, let's
>>> > match the n
On Mon, 2016-09-05 at 14:31 +0300, Dmitry Gutov wrote:
> On 05.09.2016 14:19, Oliver Neukum wrote:
>
> > You add the device to the kernel quirks list. But if
> > you don't use autosuspend, the point is moot.
>
> The device does get spinned down (after not using it for a while, I have
> to wait b
On 09/06/16 08:44, Felipe Balbi wrote:
Hi,
Felipe Balbi writes:
> According to USB 3.1 Specification, that field is 2
> bytes wide and is named with a 'w' prefix, not 'b'.
>
> Just to make grepping in the spec easier, let's
> match the name.
>
> Signed-off-by: Felipe Balbi
I'll wait for anot
On 5 September 2016 at 17:58, Alan Stern wrote:
> On Mon, 5 Sep 2016, Ritesh Raj Sarraf wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On Sun, 2016-09-04 at 15:46 -0400, Alan Stern wrote:
>> >
>> > This is not the problem I was discussing with Ulf. The problem was why
>> > t
On Tue, Sep 06, 2016 at 10:45:19AM +0300, Felipe Balbi wrote:
> Stefan Agner writes:
> > According to the device tree bindings the vcc-supply is optional.
This is nonsense unless the device can work without this supply. Given
that the supply is called VCC that doesn't seem entirely likely.
> >
We get a few warnings when building kernel with W=1:
drivers/net/usb/lan78xx.c:1182:6: warning: no previous prototype for
'lan78xx_defer_kevent' [-Wmissing-prototypes]
drivers/net/usb/lan78xx.c:1409:5: warning: no previous prototype for
'lan78xx_nway_reset' [-Wmissing-prototypes]
drivers/net/usb/
Mark,
Stefan Agner writes:
> According to the device tree bindings the vcc-supply is optional.
> So far the driver did request the regulator using devm_regulator_get
> which creates a dummy regulator for convenience. Since we can have
> the supply unconnected, we should make use of the optional
Hi,
NeilBrown writes:
> Firstly, you have made the current limit associated with each cable type
> configurable (__usb_charger_set_cur_limit_by_type). This is nonsense.
> The standard (e.g. BC-1.2) declares what the current limits are. There
> is no reason for those not to be hard coded.
I h
53 matches
Mail list logo
