The kernel-doc for the of_irq_get[_byname]() is clearly inadequate in
describing the return values -- of_irq_get_byname() is documented better
than of_irq_get() but it still doesn't mention that 0 is returned iff
irq_create_of_mapping() fails (it doesn't return an error code in this
case).
On Sat, May 28, 2016 at 12:57 PM, George Spelvin
wrote:
> Okay, Linus, it's still warm from the oven, but I think it's fully baked.
Hmm. Whioch commit did you use as a base for this? It's not plain 4.6,
but it's not toay's git either.
I did find a point where this applies, but it would be even
of_irq_get[_byname]() return 0 iff irq_create_of_mapping() call fails.
Returning both error code and 0 on failure is a sign of a misdesigned API.
We should rely on the platform IRQ resource in this case, not return 0,
especially as 0 can be a valid IRQ resource too...
Fixes: aff008ad813c
Oh! I based in on 0fed3ac866eabf01924457921ee3684c8e4c9005, which
I hope makes sense.
On 05/27/2016 08:36 PM, Mark Brown wrote:
Personally the way I parse this situation is that the kernel is taking
a look at what's in the DT and making an effort to present it usefully
in the running systems. Fixing our current interpretation in stone as
a supported thing when we don't have to
On 05/28/2016 01:24 AM, Robert Jarzmik wrote:
Guenter Roeck writes:
Hi,
your mainline commit f806dac5938b ("ARM: pxa: activate pinctrl for device-tree
machines") causes various non-devicetree systems to fail with the following
error messages when running a pxa_defconfig image.
Ah yes,
of_irq_get() returns 0 iff irq_create_of_mapping() call fails. Returning
both error code and 0 on failure is a sign of a misdesigned API. Return
-ENXIO instead like one of the callers, platform_get_irq(), does; fix up
the kernel-doc as well...
Signed-off-by: Sergei Shtylyov
---
The patch is
Release call is ignoring the return code from reset call and can
potentially continue even though reset call failed.
If reset_required module parameter is set, this patch is going
to validate the return code and will cause stack dump with
WARN_ON and warn the user of failure.
Signed-off-by:
Creating a new function to determine if this driver supports reset
function or not. This is an attempt to abstract device tree calls
from the rest of the code.
Signed-off-by: Sinan Kaya
Reviewed-by: Eric Auger
---
drivers/vfio/platform/vfio_platform_common.c | 7 ++-
1 file changed, 6
The code was allowing platform devices to be used without a supporting
VFIO reset driver. The hardware can be left in some inconsistent state
after a guest machine abort.
The reset driver will put the hardware back to safe state and disable
interrupts before returning the control back to the host
The device tree code checks for the presence of a reset driver and calls
the of_reset function pointer by looking up the reset driver as a module.
ACPI defines _RST method to perform device level reset. After the _RST
method is executed, the OS can resume using the device. _RST method is
expected
Open call is ignoring the return code from reset call and can
potentially continue even though reset call failed.
If reset_required module parameter is set, this patch is going
to validate the return code and will abort open if reset fails.
Signed-off-by: Sinan Kaya
---
Getting ready to bring out extra debug information to the caller
so that more verbose information can be printed when an error is
observed.
Signed-off-by: Sinan Kaya
---
drivers/vfio/platform/vfio_platform_common.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
The reset call sequence seems to replicate itself multiple times
across the file. Grouping them together for maintenance reasons.
Signed-off-by: Sinan Kaya
Reviewed-by: Eric Auger
---
drivers/vfio/platform/vfio_platform_common.c | 30 +---
1 file changed, 14
The code is using the compatible DT string to associate a reset driver
with the actual device itself. The compatible string does not exist on
ACPI based systems. HID is the unique identifier for a device driver
instead.
Signed-off-by: Sinan Kaya
---
drivers/vfio/platform/vfio_platform_common.c
The EFI firmware on Macs contains a full-fledged network stack for
downloading OS X images from osrecovery.apple.com. Unfortunately
on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331
wireless card on every boot and leaves it enabled even after
ExitBootServices has been called. The
On Thu, May 26, 2016 at 9:16 AM, Viresh Kumar wrote:
> On 25-05-16, 19:53, Steve Muckle wrote:
>> The slow-path frequency transition path is relatively expensive as it
>> requires waking up a thread to do work. Should support be added for
>> remote CPU cpufreq updates that is also expensive since
Added Vishay Capella CM36672 Proximity Sensor IIO driver. Support both
ACPI and Device Tree.
Signed-off-by: Kevin Tsai
---
.../devicetree/bindings/i2c/trivial-devices.txt| 1 +
.../devicetree/bindings/iio/light/cm36672.txt | 54 ++
MAINTAINERS
Hi,
I am Kristi and i saw your contact through google page of your country which
impress me and i feel we can be friends to share ideals and reason together for
good,if not bad then let us know more about each other and i hope there will be
no problem for us to be friend with no bad
Hello,
On (05/27/16 18:04), Minchan Kim wrote:
> > It is fundamentally impossible to get a list of all *potential*
> > algorithms if you allow loadable modules. By definition someone
> > could load a new module and thus introduce a new algorithm.
>
> Thanks for the quick response. I understand
---
drivers/input/input-mt.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/input/input-mt.c b/drivers/input/input-mt.c
index 54fce56..b89aaa7 100644
--- a/drivers/input/input-mt.c
+++ b/drivers/input/input-mt.c
@@ -218,8 +218,17 @@ void
From: David Miller
Date: Fri, 27 May 2016 15:51:37 -0700 (PDT)
> I'm trying to figure out the same thing myself.
Ok, mystery solved.
The basic problem is that we don't handle unaligned stacks on return to
userspace
%100 properly. We would also no handle a stack whose access would trigger a
Instead of using device tree, assuming you have firmware control,
another way could be to add a firmware feature:
for instance, there is one EC_FEATURE_PWM_FAN, the fan PWM, one for
the keyboard lightning as well. (see num ec_feature_code)
By adding one more, you let cros_ec_dev load the platform
On Fri, May 27, 2016 at 6:39 PM, Brian Norris wrote:
> Use the new ChromeOS EC EC_CMD_PWM_{GET,SET}_DUTY commands to control
> one or more PWMs attached to the Embedded Controller. Because the EC
> allows us to modify the duty cycle (as a percentage, where U16_MAX is
> 100%) but not the period,
I see:
fs/dcache.c:1673: undefined reference to `hashlen_string'
For:
total: 148 pass: 22 fail: 126
I didn't bisect, but I strongly suspect commit fcfd2fbf22d2 ("fs/namei.c:
Add hashlen_string() function") because the new function is not provided
if DCACHE_WORD_ACCESS is not enabled.
> Reverting 468a9428521e, 2a18da7a9c78, and fcfd2fbf22d2 fixed the problem
> for me in a couple of test builds, but I don't know if all three patches
> need to be reverted, or if reverting those patches fixes the problem for
> all builds, or if the revert is sufficient.
Oh, fuck me so fucking
The original name was simply hash_string(), but that conflicted with a
function with that name in drivers/base/power/trace.c, and I decided that
calling it "hashlen_" was better anyway.
But you have to do it in two places.
Signed-off-by: George Spelvin
Fixes:
Thank you or the prompt report which saved me the greater embarrassment
of seeing the bug in -rc1.
301 - 328 of 328 matches
Mail list logo
