Re: Build errors in mainline due to "fs/namei.c:,Add hashlen_string() function"

Thank you or the prompt report which saved me the greater embarrassment of seeing the bug in -rc1.

Re: Build errors in mainline due to "fs/namei.c:,Add hashlen_string() function"

Thank you or the prompt report which saved me the greater embarrassment of seeing the bug in -rc1.

[PATCH] Rename other copy of hash_string to hashlen_string

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:

[PATCH] Rename other copy of hash_string to hashlen_string

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:

Re: Build errors in mainline due to "fs/namei.c:,Add hashlen_string() function"

> 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

Re: Build errors in mainline due to "fs/namei.c:,Add hashlen_string() function"

> 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

Build errors in mainline due to "fs/namei.c:,Add hashlen_string() function"

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.

Build errors in mainline due to "fs/namei.c:,Add hashlen_string() function"

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.

Re: [PATCH 4/4] pwm: add ChromeOS EC PWM driver

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 >

Re: [PATCH 4/4] pwm: add ChromeOS EC PWM driver

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,

Re: [PATCH 3/4] doc: dt: pwm: add binding for ChromeOS EC PWM

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

Re: [PATCH 3/4] doc: dt: pwm: add binding for ChromeOS EC PWM

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

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

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

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

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

[PATCH] Input: /input/input-mt.c Emit BTN_TOO_FINGER in function input_mt_report_pointer_emulation if touchpad meets hover condition Signed-off-by: KT Liao <kt.l...@emc.com.tw>

--- 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

[PATCH] Input: /input/input-mt.c Emit BTN_TOO_FINGER in function input_mt_report_pointer_emulation if touchpad meets hover condition Signed-off-by: KT Liao

--- 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

Re: [PATCH 5/7] zram: use crypto api to check alg availability

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

Re: [PATCH 5/7] zram: use crypto api to check alg availability

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

Hello

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

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

[PATCH 1/1] iio: light: Added CM36672 Proximity Sensor Driver.

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

[PATCH 1/1] iio: light: Added CM36672 Proximity Sensor Driver.

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

Re: [PATCH v2 3/3] cpufreq: schedutil: map raw required frequency to driver frequency

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

Re: [PATCH v2 3/3] cpufreq: schedutil: map raw required frequency to driver frequency

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

[PATCH] x86: Add early quirk to reset Apple AirPort card

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

[PATCH] x86: Add early quirk to reset Apple AirPort card

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

[PATCH V6 3/8] vfio: platform: add support for ACPI probe

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 ---

[PATCH V6 3/8] vfio: platform: add support for ACPI probe

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

[PATCH V6 5/8] vfio: platform: call _RST method when using ACPI

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

[PATCH V6 7/8] vfio: platform: check reset call return code during open

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 ---

[PATCH V6 4/8] vfio: platform: add extra debug info argument to call reset

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

[PATCH V6 1/8] vfio: platform: move reset call to a common function

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

[PATCH V6 5/8] vfio: platform: call _RST method when using ACPI

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

[PATCH V6 7/8] vfio: platform: check reset call return code during open

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 ---

[PATCH V6 4/8] vfio: platform: add extra debug info argument to call reset

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

[PATCH V6 1/8] vfio: platform: move reset call to a common function

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

[PATCH V6 6/8] vfio, platform: make reset driver a requirement by default

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

[PATCH V6 8/8] vfio: platform: check reset call return code during release

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:

[PATCH V6 2/8] vfio: platform: determine reset capability

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 ---

[PATCH V6 8/8] vfio: platform: check reset call return code during release

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:

[PATCH V6 2/8] vfio: platform: determine reset capability

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

[PATCH V6 6/8] vfio, platform: make reset driver a requirement by default

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

[PATCH] of: irq: don't return 0 from of_irq_get()

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

[PATCH] of: irq: don't return 0 from of_irq_get()

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

Re: pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl for device-tree machines'

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

Re: pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl for device-tree machines'

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,

Re: [PATCH] devicetree - document using aliases to set spi bus number.

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

Re: [PATCH] devicetree - document using aliases to set spi bus number.

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

Re: [PATCH v3 00/10] String hash improvements

Oh! I based in on 0fed3ac866eabf01924457921ee3684c8e4c9005, which I hope makes sense.

Re: [PATCH v3 00/10] String hash improvements

Oh! I based in on 0fed3ac866eabf01924457921ee3684c8e4c9005, which I hope makes sense.

[PATCH] platform: don't return 0 from platform_get_irq[_byname]() on error

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

[PATCH] platform: don't return 0 from platform_get_irq[_byname]() on error

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

Re: [PATCH v3 00/10] String hash improvements

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

Re: [PATCH v3 00/10] String hash improvements

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

[PATCH] of: irq: fix of_irq_get[_byname]() kernel-doc

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).

[PATCH] of: irq: fix of_irq_get[_byname]() kernel-doc

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).

[PATCH v3 04/10] Change hash_64() return value to 32 bits

That's all that's ever asked for, and it makes the return type of hash_long() consistent. It also allows (upcoming patch) an optimized implementation of hash_64 on 32-bit machines. I tried adding a BUILD_BUG_ON to ensure the number of bits requested was never more than 32 (most callers use a

[PATCH v3 02/10] fs/namei.c: Add hashlen_string() function

We'd like to make more use of the highly-optimized dcache hash functions throughout the kernel, rather than have every subsystem create its own, and a function that hashes basic null-terminated strings is required for that. (The name is to emphasize that it returns both hash and length.) It's

[PATCH v3 03/10] : Define hash_str() in terms of hashlen_string()

Finally, the first use of previous two patches: eliminate the separate ad-hoc string hash functions in the sunrpc code. Now hash_str() is a wrapper around hash_string(), and hash_mem() is likewise a wrapper around full_name_hash(). Note that sunrpc code *does* call hash_mem() with a zero length,

[PATCH v3 04/10] Change hash_64() return value to 32 bits

That's all that's ever asked for, and it makes the return type of hash_long() consistent. It also allows (upcoming patch) an optimized implementation of hash_64 on 32-bit machines. I tried adding a BUILD_BUG_ON to ensure the number of bits requested was never more than 32 (most callers use a

[PATCH v3 02/10] fs/namei.c: Add hashlen_string() function

We'd like to make more use of the highly-optimized dcache hash functions throughout the kernel, rather than have every subsystem create its own, and a function that hashes basic null-terminated strings is required for that. (The name is to emphasize that it returns both hash and length.) It's

[PATCH v3 03/10] : Define hash_str() in terms of hashlen_string()

Finally, the first use of previous two patches: eliminate the separate ad-hoc string hash functions in the sunrpc code. Now hash_str() is a wrapper around hash_string(), and hash_mem() is likewise a wrapper around full_name_hash(). Note that sunrpc code *does* call hash_mem() with a zero length,

[PATCH v3 07/10] : Add support for architecture-specific functions

This is just the infrastructure; there are no users yet. This is modelled on CONFIG_ARCH_RANDOM; a CONFIG_ symbol declares the existence of . That file may define its own versions of various functions, and define HAVE_* symbols (no CONFIG_ prefix!) to suppress the generic ones. Included is a

[PATCH v3 06/10] fs/namei.c: Improve dcache hash function

Patch 0fed3ac866 improved the hash mixing, but the function is slower than necessary; there's a 7-instruction dependency chain (10 on x86) each loop iteration. Word-at-a-time access is a very tight loop (which is good, because link_path_walk() is one of the hottest code paths in the entire

[PATCH v3 09/10] microblaze: Add

Microblaze is an FPGA soft core that can be configured various ways. If it is configured without a multiplier, the standard __hash_32() will require a call to __mulsi3, which is a slow software loop. Instead, use a shift-and-add sequence for the constant multiply. GCC knows how to do this, but

[PATCH v3 07/10] : Add support for architecture-specific functions

This is just the infrastructure; there are no users yet. This is modelled on CONFIG_ARCH_RANDOM; a CONFIG_ symbol declares the existence of . That file may define its own versions of various functions, and define HAVE_* symbols (no CONFIG_ prefix!) to suppress the generic ones. Included is a

[PATCH v3 06/10] fs/namei.c: Improve dcache hash function

Patch 0fed3ac866 improved the hash mixing, but the function is slower than necessary; there's a 7-instruction dependency chain (10 on x86) each loop iteration. Word-at-a-time access is a very tight loop (which is good, because link_path_walk() is one of the hottest code paths in the entire

[PATCH v3 09/10] microblaze: Add

Microblaze is an FPGA soft core that can be configured various ways. If it is configured without a multiplier, the standard __hash_32() will require a call to __mulsi3, which is a slow software loop. Instead, use a shift-and-add sequence for the constant multiply. GCC knows how to do this, but

[PATCH v3 01/10] Pull out string hash to

... so they can be used without the rest of The hashlen_* macros will make sense next patch. Signed-off-by: George Spelvin --- include/linux/dcache.h | 27 + include/linux/stringhash.h | 72 ++ 2 files

[PATCH v3 10/10] h8300: Add

This will improve the performance of hash_32() and hash_64(), but due to complete lack of multi-bit shift instructions on H8, performance will still be bad in surrounding code. Designing H8-specific hash algorithms to work around that is a separate project. (But if the maintainers would like to

[PATCH v3 01/10] Pull out string hash to

... so they can be used without the rest of The hashlen_* macros will make sense next patch. Signed-off-by: George Spelvin --- include/linux/dcache.h | 27 + include/linux/stringhash.h | 72 ++ 2 files changed, 73 insertions(+),

[PATCH v3 10/10] h8300: Add

This will improve the performance of hash_32() and hash_64(), but due to complete lack of multi-bit shift instructions on H8, performance will still be bad in surrounding code. Designing H8-specific hash algorithms to work around that is a separate project. (But if the maintainers would like to

[PATCH v3 08/10] m68k: Add

This provides a multiply by constant GOLDEN_RATIO_32 = 0x61C88647 for the original mc68000, which lacks a 32x32-bit multiply instruction. Yes, the amount of optimization effort put in is excessive. :-) Shift-add chain found by Yevgen Voronenko's Hcub algorithm at

[PATCH v3 08/10] m68k: Add

This provides a multiply by constant GOLDEN_RATIO_32 = 0x61C88647 for the original mc68000, which lacks a 32x32-bit multiply instruction. Yes, the amount of optimization effort put in is excessive. :-) Shift-add chain found by Yevgen Voronenko's Hcub algorithm at

[PATCH v3 00/10] String hash improvements

Okay, Linus, it's still warm from the oven, but I think it's fully baked. Special thanks to J. Bruce Fields for testing and finding bugs in v1. (I learned some humbling lessons about "obviously correct" code.) On the arch-specific front, the m68k assembly has been tested in a standalone test

[PATCH v3 05/10] Eliminate bad hash multipliers from hash_32() and hash_64()

The "simplified" prime multipliers made very bad hash functions, so get rid of them. This completes the work of 689de1d6ca. To avoid the inefficiency which was the motivation for the "simplified" multipliers, hash_64() on 32-bit systems is changed to use a different algorithm. It makes two

[PATCH v3 00/10] String hash improvements

Okay, Linus, it's still warm from the oven, but I think it's fully baked. Special thanks to J. Bruce Fields for testing and finding bugs in v1. (I learned some humbling lessons about "obviously correct" code.) On the arch-specific front, the m68k assembly has been tested in a standalone test

[PATCH v3 05/10] Eliminate bad hash multipliers from hash_32() and hash_64()

The "simplified" prime multipliers made very bad hash functions, so get rid of them. This completes the work of 689de1d6ca. To avoid the inefficiency which was the motivation for the "simplified" multipliers, hash_64() on 32-bit systems is changed to use a different algorithm. It makes two

Re: [PATCH v5 1/4] isa: Allow ISA-style drivers on modern systems

On Fri, May 27, 2016 at 3:08 PM, William Breathitt Gray wrote: > Several modern devices, such as PC/104 cards, are expected to run on > modern systems via an ISA bus interface. Since ISA is a legacy interface > for most modern architectures, ISA support should remain

Re: [PATCH v5 1/4] isa: Allow ISA-style drivers on modern systems

On Fri, May 27, 2016 at 3:08 PM, William Breathitt Gray wrote: > Several modern devices, such as PC/104 cards, are expected to run on > modern systems via an ISA bus interface. Since ISA is a legacy interface > for most modern architectures, ISA support should remain disabled in > general.

Re: [PATCH] crypto: s5p-sss - Use consistent indentation for variables and members

Hi Krzysztof, On 27.05.2016 14:49, Krzysztof Kozlowski wrote: > Bring some consistency by: > 1. Replacing fixed-space indentation of structure members with just >tabs. > 2. Remove indentation in declaration of local variable between type and >name. Driver was mixing usage of such

Re: [PATCH] crypto: s5p-sss - Use consistent indentation for variables and members

Hi Krzysztof, On 27.05.2016 14:49, Krzysztof Kozlowski wrote: > Bring some consistency by: > 1. Replacing fixed-space indentation of structure members with just >tabs. > 2. Remove indentation in declaration of local variable between type and >name. Driver was mixing usage of such

[PULL REQUEST] i2c for 4.7

Linus, here is the pull request from I2C with the fix for a regression introduced yesterday. The regression didn't show up here locally because I did not have PAGE_POISONING enabled. And buildbots discovered this only after it hit your tree. Thanks to Dan for the quick response. Really sorry

[PULL REQUEST] i2c for 4.7

Linus, here is the pull request from I2C with the fix for a regression introduced yesterday. The regression didn't show up here locally because I did not have PAGE_POISONING enabled. And buildbots discovered this only after it hit your tree. Thanks to Dan for the quick response. Really sorry

Re: [PATCH 2/4] dt-bindings: Update Renesas R-Car FCP DT binding

Hi Kieran, On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham wrote: > The FCP driver, can also support the FCPF variant for FDP1 compatible > processing. > > Signed-off-by: Kieran Bingham Thanks for your patch! > --- >

Re: [PATCH 2/4] dt-bindings: Update Renesas R-Car FCP DT binding

Hi Kieran, On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham wrote: > The FCP driver, can also support the FCPF variant for FDP1 compatible > processing. > > Signed-off-by: Kieran Bingham Thanks for your patch! > --- > Documentation/devicetree/bindings/media/renesas,fcp.txt | 3 ++- > 1 file

Re: [PATCH 3/4] dt-bindings: Document Renesas R-Car FCP power-domains usage

Hi Kieran, On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham wrote: > The example misses the power-domains usage, and documentation that the > property is used by the node. > > Signed-off-by: Kieran Bingham Thanks for your patch! > --- >

Re: [PATCH 3/4] dt-bindings: Document Renesas R-Car FCP power-domains usage

Hi Kieran, On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham wrote: > The example misses the power-domains usage, and documentation that the > property is used by the node. > > Signed-off-by: Kieran Bingham Thanks for your patch! > --- > Documentation/devicetree/bindings/media/renesas,fcp.txt

Re: 4.7-rc0: redshift stopped working on intel display

On Sat 2016-05-28 12:12:06, Pavel Machek wrote: > Hi! > > It looks like redshift stopped working. Even pretty crazy settings > have no visible effect: > > pavel@amd:~$ redshift -O 1500 -g 6.6:6.6:6.6 > Using method `randr'. > pavel@amd:~$ redshift -x > Using method `randr'. > pavel@amd:~$ uname

Re: 4.7-rc0: redshift stopped working on intel display

On Sat 2016-05-28 12:12:06, Pavel Machek wrote: > Hi! > > It looks like redshift stopped working. Even pretty crazy settings > have no visible effect: > > pavel@amd:~$ redshift -O 1500 -g 6.6:6.6:6.6 > Using method `randr'. > pavel@amd:~$ redshift -x > Using method `randr'. > pavel@amd:~$ uname

Re: [PATCH] mtd: brcmnand: Add v7.2 controller support

Hello, On Fri, 27 May 2016 14:58:11 -0700, Florian Fainelli wrote: > + if (ctrl->nand_version >= 0x0702) > + bits = 7; > if (ctrl->nand_version >= 0x0600) Don't you want an "else if" here ? Otherwise, even for the 7.2 version of your controller bits will be set to 1.

Re: [PATCH] mtd: brcmnand: Add v7.2 controller support

Hello, On Fri, 27 May 2016 14:58:11 -0700, Florian Fainelli wrote: > + if (ctrl->nand_version >= 0x0702) > + bits = 7; > if (ctrl->nand_version >= 0x0600) Don't you want an "else if" here ? Otherwise, even for the 7.2 version of your controller bits will be set to 1.

Re: [PATCH 2/3] iio: adc: mxs-lradc: Add support for adc driver

On Sun, May 1, 2016 at 6:38 PM, Jonathan Cameron wrote: > On 29/04/16 12:48, Ksenija Stanojevic wrote: >> Add mxs-lradc adc driver. >> >> Signed-off-by: Ksenija Stanojevic > Mostly looking good. A few nitpicks and suggestions inline. > > Jonathan

Re: [PATCH 2/3] iio: adc: mxs-lradc: Add support for adc driver

On Sun, May 1, 2016 at 6:38 PM, Jonathan Cameron wrote: > On 29/04/16 12:48, Ksenija Stanojevic wrote: >> Add mxs-lradc adc driver. >> >> Signed-off-by: Ksenija Stanojevic > Mostly looking good. A few nitpicks and suggestions inline. > > Jonathan >> --- >> drivers/iio/adc/Kconfig | 37

Re: [PATCH 3/3] input: touchscreen: mxs-lradc: Add support for touchscreen

On Sat, Apr 30, 2016 at 1:36 AM, Dmitry Torokhov wrote: > Hi Ksenija, > > On Fri, Apr 29, 2016 at 01:49:11PM +0200, Ksenija Stanojevic wrote: >> Add mxs-lradc touchscreen driver. >> >> Signed-off-by: Ksenija Stanojevic >> --- >>

Re: [PATCH 3/3] input: touchscreen: mxs-lradc: Add support for touchscreen

On Sat, Apr 30, 2016 at 1:36 AM, Dmitry Torokhov wrote: > Hi Ksenija, > > On Fri, Apr 29, 2016 at 01:49:11PM +0200, Ksenija Stanojevic wrote: >> Add mxs-lradc touchscreen driver. >> >> Signed-off-by: Ksenija Stanojevic >> --- >> drivers/input/touchscreen/Kconfig| 14 +- >>

Re: [PATCH 3/3] input: touchscreen: mxs-lradc: Add support for touchscreen

On Sun, May 1, 2016 at 6:47 PM, Jonathan Cameron wrote: > On 29/04/16 12:49, Ksenija Stanojevic wrote: >> Add mxs-lradc touchscreen driver. >> >> Signed-off-by: Ksenija Stanojevic > The only real thing this raises for me is why we are grabbing IRQs

Re: [PATCH 3/3] input: touchscreen: mxs-lradc: Add support for touchscreen

On Sun, May 1, 2016 at 6:47 PM, Jonathan Cameron wrote: > On 29/04/16 12:49, Ksenija Stanojevic wrote: >> Add mxs-lradc touchscreen driver. >> >> Signed-off-by: Ksenija Stanojevic > The only real thing this raises for me is why we are grabbing IRQs that I > don't think this driver even cares

Re: [PATCH v5 3/4] iio: stx104: Allow build for X86_64

On 27/05/16 23:09, William Breathitt Gray wrote: > With the introduction of the ISA_BUS_API Kconfig option, ISA-style > drivers may be built for X86_64 architectures. This patch changes the > ISA Kconfig option dependency of the Apex Embedded Systems STX104 DAC > driver to ISA_BUS_API, thus

Re: [PATCH v5 3/4] iio: stx104: Allow build for X86_64

On 27/05/16 23:09, William Breathitt Gray wrote: > With the introduction of the ISA_BUS_API Kconfig option, ISA-style > drivers may be built for X86_64 architectures. This patch changes the > ISA Kconfig option dependency of the Apex Embedded Systems STX104 DAC > driver to ISA_BUS_API, thus

  1   2   3   4   >