On Mon, Oct 16, 2017 at 4:31 AM, Greg Kroah-Hartman
wrote:
> I don't remember, maybe someone needs to just resend them without the
> "RFC" marking, as I of course can't apply a patch series like that :)
I can resend if Nicolai doesn't get to it before me. I tested that
they fix this problem but I
this debugfs change?
It seems to me that the USB locking is reasonable but the debugfs
global srcu is overly restrictive. This could lead to unexpected lock
inversion any time a driver shares a mutex between its debugfs read
and removal paths.
Backtrace below. Thanks!
-Tyler Hall
This is easier
for Armada XP, so I would think they would
apply to all flavors.
mvebu-soc-id: MVEBU SoC ID=0x7846, Rev=0x2
Hopefully either of our queries will be answered and we can make a
more informed decision on this.
Thanks,
Tyler
On Wed, Feb 25, 2015 at 2:47 PM, Tyler Hall wrote:
> Hi Gregory, Eduardo,
Hi Gregory, Eduardo,
On Wed, Feb 25, 2015 at 05:10:14PM +0100, Gregory CLEMENT wrote:
> By using it by default do you mean removing marvell,armadaxp-thermal
> and adding armadaxp-filtered-thermal instead ?
Yes, replacing it in device tree. For me,
/sys/class/thermal/thermal_zone0/temp returns the
Eduardo,
On Tue, Feb 24, 2015 at 1:36 PM, Eduardo Valentin wrote:
> The fix seams reasonable. Although, it remains the question what is
> applicability to other Armada chips? Besides, shouldn't we simply use it
> by default? Also, do you plan to send updates in the DTS files?
As far as I can tel
onding
device tree update, the temperature is much more stable.
Signed-off-by: Tyler Hall
---
If there's a better way to handle this than a separate binding, I'm open to
suggestions.
My conclusions about these registers are based on experimental data. The
documentation is very sparse, bu
chips if a node-match is found and
>>> the translation fails.
>>>
>>> Signed-off-by: Hans Holmberg
>>
>> Acked-by: Alexandre Courbot
> Tested-by: Robert Jarzmik
> (on arm pxa architecture)
Tested-by: Tyler Hall
With gpio-pxa (multiple chips per of
> The issue with multiple gpiochips per of-node could be worked around as
> followed I believe, comments?
>
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 08261f2..43984ab 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -47,11 +47,12 @@
Hi,
Commit 7b8792b ("gpiolib: of: Correct error handling in
of_get_named_gpiod_flags") seems to break the ability to use DT
bindings to reference this driver's GPIOs by phandle for banks above
the first.
The issue is that gpio-pxa registers multiple gpio chips - one for
each bank - but they're al
0 r7:ec027000 r6:ea717eb8 r5: r4:
Signed-off-by: Tyler Hall
Cc: Oliver Hartkopp
Cc: Andre Naujoks
Cc: David S. Miller
Cc: linux-kernel@vger.kernel.org
---
drivers/net/slip/slip.c | 36 ++--
drivers/net/slip/slip.h | 1 +
2 files changed, 27 inserti
The commit "slip: Fix deadlock in write_wakeup" fixes a deadlock caused
by a change made in both slcan and slip. This is a direct port of that
fix.
Signed-off-by: Tyler Hall
Cc: Oliver Hartkopp
Cc: Andre Naujoks
Cc: David S. Miller
Cc: linux-kernel@vger.kernel.org
---
drivers/net/c
11 matches
Mail list logo
