RE: [PATCH] mei: remove dev_err message on an unsupported ioctl

> > On Tue, Feb 27, 2018 at 05:26:22PM +, Winkler, Tomas wrote: > > > > > > From: Colin Ian King > > > > > > Currently the driver spams the kernel log on unsupported ioctls > > > which is unnecessary as the ioctl returns -ENOIOCTLCMD to indicate this > anyway. > > >

RE: [PATCH] mei: remove dev_err message on an unsupported ioctl

> > On Tue, Feb 27, 2018 at 05:26:22PM +, Winkler, Tomas wrote: > > > > > > From: Colin Ian King > > > > > > Currently the driver spams the kernel log on unsupported ioctls > > > which is unnecessary as the ioctl returns -ENOIOCTLCMD to indicate this > anyway. > > > I suspect this was

Re: [PATCH v2 3/3] objtool: use global host flags for compilation

On Tue, Feb 27, 2018 at 09:55:23PM +0100, Robin Jarry wrote: > 2018-02-27, Josh Poimboeuf: > > On Mon, Feb 26, 2018 at 07:41:48PM +0100, Robin Jarry wrote: > [snip] > > > ifdef CONFIG_STACK_VALIDATION > > >has_libelf := $(call try-run,\ > > > - echo "int main() {}" | $(HOSTCC) -xc -o

Re: [PATCH v2 3/3] objtool: use global host flags for compilation

On Tue, Feb 27, 2018 at 09:55:23PM +0100, Robin Jarry wrote: > 2018-02-27, Josh Poimboeuf: > > On Mon, Feb 26, 2018 at 07:41:48PM +0100, Robin Jarry wrote: > [snip] > > > ifdef CONFIG_STACK_VALIDATION > > >has_libelf := $(call try-run,\ > > > - echo "int main() {}" | $(HOSTCC) -xc -o

Re: [PATCH] pci-iov: Add support for unmanaged SR-IOV

On Tue, 27 Feb 2018 11:06:54 -0800 Alexander Duyck wrote: > From: Alexander Duyck > > This patch is meant to add support for SR-IOV on devices when the VFs are > not managed by the kernel. Examples of recent patches attempting to do this

Re: [PATCH] pci-iov: Add support for unmanaged SR-IOV

On Tue, 27 Feb 2018 11:06:54 -0800 Alexander Duyck wrote: > From: Alexander Duyck > > This patch is meant to add support for SR-IOV on devices when the VFs are > not managed by the kernel. Examples of recent patches attempting to do this > include: It appears to enable sriov when the _pf_ is

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

On Tue, Feb 27, 2018 at 09:52:31PM +0100, Robin Jarry wrote: > 2018-02-27, Josh Poimboeuf: > > In Documentation/kbuild/kbuild.txt, we have the following environment > > variables: > > > > KCFLAGS > > -- > > Additional options to the C compiler

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

On Tue, Feb 27, 2018 at 09:52:31PM +0100, Robin Jarry wrote: > 2018-02-27, Josh Poimboeuf: > > In Documentation/kbuild/kbuild.txt, we have the following environment > > variables: > > > > KCFLAGS > > -- > > Additional options to the C compiler

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

Hi Thomas, On 2/27/2018 11:52 AM, Reinette Chatre wrote: > On 2/27/2018 2:36 AM, Thomas Gleixner wrote: >> Let's assume its real, >> so you could do the following: >> >> mkdir group <- acquires closid >> echo locksetup > mode<- Creates 'lockarea' file >> echo L2:0 > lockarea >>

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

Hi Thomas, On 2/27/2018 11:52 AM, Reinette Chatre wrote: > On 2/27/2018 2:36 AM, Thomas Gleixner wrote: >> Let's assume its real, >> so you could do the following: >> >> mkdir group <- acquires closid >> echo locksetup > mode<- Creates 'lockarea' file >> echo L2:0 > lockarea >>

Re: [PATCH] pvcalls-front: 64-bit align flags

On Tue, 27 Feb 2018, Boris Ostrovsky wrote: > On 02/27/2018 02:54 PM, Stefano Stabellini wrote: > > We are using test_and_* operations on the status and flag fields of > > struct sock_mapping. However, these functions require the operand to be > > 64-bit aligned on arm64. Currently, only status is

RE: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure

> -Original Message- > From: Borislav Petkov [mailto:b...@suse.de] > Sent: Tuesday, February 27, 2018 2:10 PM > To: Ghannam, Yazen > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > ard.biesheu...@linaro.org; x...@kernel.org; Tony Luck >

Re: [PATCH] pvcalls-front: 64-bit align flags

On Tue, 27 Feb 2018, Boris Ostrovsky wrote: > On 02/27/2018 02:54 PM, Stefano Stabellini wrote: > > We are using test_and_* operations on the status and flag fields of > > struct sock_mapping. However, these functions require the operand to be > > 64-bit aligned on arm64. Currently, only status is

RE: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure

> -Original Message- > From: Borislav Petkov [mailto:b...@suse.de] > Sent: Tuesday, February 27, 2018 2:10 PM > To: Ghannam, Yazen > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > ard.biesheu...@linaro.org; x...@kernel.org; Tony Luck > > Subject: Re: [PATCH v2 3/8] efi:

Re: [RFC PATCH] Randomization of address chosen by mmap.

On 2/27/18 9:52 PM, Kees Cook wrote: > I'd like more details on the threat model here; if it's just a matter > of .so loading order, I wonder if load order randomization would get a > comparable level of uncertainty without the memory fragmentation, This also seems to assume that leaking the

Re: [RFC PATCH] Randomization of address chosen by mmap.

On 2/27/18 9:52 PM, Kees Cook wrote: > I'd like more details on the threat model here; if it's just a matter > of .so loading order, I wonder if load order randomization would get a > comparable level of uncertainty without the memory fragmentation, This also seems to assume that leaking the

[PATCH v2] ARM: imx: avic: set low-power interrupt mask for imx25

imx25 contains two registers (LPIMR0 and 1) to define which interrupts are enabled in low-power mode. As of today, those two registers are configured to enable all interrupts. Before going to low-power mode, the AVIC's INTENABLEH and INTENABLEL registers are configured to enable only those

[PATCH v2] ARM: imx: avic: set low-power interrupt mask for imx25

imx25 contains two registers (LPIMR0 and 1) to define which interrupts are enabled in low-power mode. As of today, those two registers are configured to enable all interrupts. Before going to low-power mode, the AVIC's INTENABLEH and INTENABLEL registers are configured to enable only those

Re: [PATCH RFC] ARM: imx: avic: set low-power interrupt mask for imx25

Hello Shawn and all, Thus wrote Shawn Guo (shawn...@kernel.org): > > +static void __iomem *avic_base, *mx25_ccm_base; > Keep avic_base line untouched, and add a new one for mx25_ccm_base. ok > > static struct irq_domain *domain; > > #ifdef CONFIG_FIQ > > @@ -93,6 +97,11 @@ static void

Re: [PATCH RFC] ARM: imx: avic: set low-power interrupt mask for imx25

Hello Shawn and all, Thus wrote Shawn Guo (shawn...@kernel.org): > > +static void __iomem *avic_base, *mx25_ccm_base; > Keep avic_base line untouched, and add a new one for mx25_ccm_base. ok > > static struct irq_domain *domain; > > #ifdef CONFIG_FIQ > > @@ -93,6 +97,11 @@ static void

[PATCH v1 1/4] ASoC: codecs: pcm179x: Add PCM1789 id

To prepare the support for the PCM1789, add a new compatible and use the i2c_id to handle, later, the differences between these two DACs even if they are pretty similar. Signed-off-by: Mylène Josserand --- Documentation/devicetree/bindings/sound/pcm179x.txt | 2 +-

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

On Wed, Feb 21, 2018 at 2:55 AM, Andrzej Hajda wrote: > OF graph describes MHL data lanes between MHL and respective USB > connector. > > Signed-off-by: Andrzej Hajda > --- > v4: > - added missing reg property in connector's port node (Krzysztof) > --- >

[PATCH v1 1/4] ASoC: codecs: pcm179x: Add PCM1789 id

To prepare the support for the PCM1789, add a new compatible and use the i2c_id to handle, later, the differences between these two DACs even if they are pretty similar. Signed-off-by: Mylène Josserand --- Documentation/devicetree/bindings/sound/pcm179x.txt | 2 +-

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

On Wed, Feb 21, 2018 at 2:55 AM, Andrzej Hajda wrote: > OF graph describes MHL data lanes between MHL and respective USB > connector. > > Signed-off-by: Andrzej Hajda > --- > v4: > - added missing reg property in connector's port node (Krzysztof) > --- >

[PATCH v1 0/4] ASoC: Add support for DAC PCM1789

Hello everyone, You will find in this series the support of Texas Instrument's DAC PCM1789. This DAC is very minimalist and is similar to PCM1792a except for some differences in registers. Series based on asoc tree, "for-next" branch (last commit 130c3888dfdc). It is important to notice that

[PATCH v1 0/4] ASoC: Add support for DAC PCM1789

Hello everyone, You will find in this series the support of Texas Instrument's DAC PCM1789. This DAC is very minimalist and is similar to PCM1792a except for some differences in registers. Series based on asoc tree, "for-next" branch (last commit 130c3888dfdc). It is important to notice that

[PATCH v1 4/4] ASoC: codecs: pcm179x: Add trigger function to perform a reset

Add trigger function to perform a reset when we are starting to play a sound. Thanks to that, the codec will not be in desynchronization state anymore and the data will be sent correctly. Signed-off-by: Mylène Josserand --- sound/soc/codecs/pcm179x-i2c.c | 4 +++

[PATCH v1 2/4] ASoC: codecs: pcm179x: Add support for PCM1789

Add PCM1789 DAC support into pcm179x file. This DAC is pretty much the same than PCM179x but some registers are differents (such as mute registers split in right/left). One particularity about this DAC is that the clocks must be always enabled. Also, an entire software reset is necessary while

[PATCH v1 2/4] ASoC: codecs: pcm179x: Add support for PCM1789

Add PCM1789 DAC support into pcm179x file. This DAC is pretty much the same than PCM179x but some registers are differents (such as mute registers split in right/left). One particularity about this DAC is that the clocks must be always enabled. Also, an entire software reset is necessary while

[PATCH v1 4/4] ASoC: codecs: pcm179x: Add trigger function to perform a reset

Add trigger function to perform a reset when we are starting to play a sound. Thanks to that, the codec will not be in desynchronization state anymore and the data will be sent correctly. Signed-off-by: Mylène Josserand --- sound/soc/codecs/pcm179x-i2c.c | 4 +++ sound/soc/codecs/pcm179x.c

[PATCH v1 3/4] ASoC: codecs: pcm179x: Add reset gpio

Add a reset gpio to be able to reset this line at startup. Signed-off-by: Mylène Josserand --- sound/soc/codecs/pcm179x.c | 20 1 file changed, 20 insertions(+) diff --git a/sound/soc/codecs/pcm179x.c b/sound/soc/codecs/pcm179x.c index

[PATCH v1 3/4] ASoC: codecs: pcm179x: Add reset gpio

Add a reset gpio to be able to reset this line at startup. Signed-off-by: Mylène Josserand --- sound/soc/codecs/pcm179x.c | 20 1 file changed, 20 insertions(+) diff --git a/sound/soc/codecs/pcm179x.c b/sound/soc/codecs/pcm179x.c index 2285a51ff9e9..0242dfd67b53 100644 ---

Re: [PATCH] pvcalls-front: 64-bit align flags

On 02/27/2018 02:54 PM, Stefano Stabellini wrote: > We are using test_and_* operations on the status and flag fields of > struct sock_mapping. However, these functions require the operand to be > 64-bit aligned on arm64. Currently, only status is 64-bit aligned. > > Make flags 64-bit aligned by

Re: [PATCH] pvcalls-front: 64-bit align flags

On 02/27/2018 02:54 PM, Stefano Stabellini wrote: > We are using test_and_* operations on the status and flag fields of > struct sock_mapping. However, these functions require the operand to be > 64-bit aligned on arm64. Currently, only status is 64-bit aligned. > > Make flags 64-bit aligned by

[PATCH 0/7] fujitsu-laptop: Consistent naming of constants

This patch series is an attempt to organize all the named constants used throughout fujitsu-laptop so that their names more clearly convey their purpose: a set of prefixes is introduced to "map" constant names to call_fext_func() parameters. The chosen constant naming patterns are a compromise

[PATCH 0/7] fujitsu-laptop: Consistent naming of constants

This patch series is an attempt to organize all the named constants used throughout fujitsu-laptop so that their names more clearly convey their purpose: a set of prefixes is introduced to "map" constant names to call_fext_func() parameters. The chosen constant naming patterns are a compromise

[PATCH 1/7] platform/x86: fujitsu-laptop: Define constants for FUNC operations

Various functions exposed by the firmware through the FUNC interface tend to use a consistent set of integers for denoting the type of operation to be performed for a specified feature. Use named constants instead of integers in each call_fext_func() invocation in order to more clearly convey the

[PATCH 1/7] platform/x86: fujitsu-laptop: Define constants for FUNC operations

Various functions exposed by the firmware through the FUNC interface tend to use a consistent set of integers for denoting the type of operation to be performed for a specified feature. Use named constants instead of integers in each call_fext_func() invocation in order to more clearly convey the

[PATCH 3/7] platform/x86: fujitsu-laptop: Define constants for FUNC feature states

Various functions exposed by the firmware through the FUNC interface allow read/write access to the state of certain features. Make sure these states are referred to by consistently named constants instead of integers in order to better convey the intent of each call_fext_func() invocation.

[PATCH 3/7] platform/x86: fujitsu-laptop: Define constants for FUNC feature states

Various functions exposed by the firmware through the FUNC interface allow read/write access to the state of certain features. Make sure these states are referred to by consistently named constants instead of integers in order to better convey the intent of each call_fext_func() invocation.

[PATCH 4/7] platform/x86: fujitsu-laptop: Rename constants defining hotkey codes

Rename KEYx_CODE constants to EVENT_HKx, so that their names better fit the OP_GET_EVENTS operation they are used with. Signed-off-by: Michał Kępień --- drivers/platform/x86/fujitsu-laptop.c | 36 +-- 1 file changed, 18 insertions(+), 18

[PATCH 4/7] platform/x86: fujitsu-laptop: Rename constants defining hotkey codes

Rename KEYx_CODE constants to EVENT_HKx, so that their names better fit the OP_GET_EVENTS operation they are used with. Signed-off-by: Michał Kępień --- drivers/platform/x86/fujitsu-laptop.c | 36 +-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git

[PATCH V3] Allow configuring whether unsigned modules taint the kernel

Distributions build kernels that are intended to satisfy multiple use-cases. One is that kernels must be usable in scenarios where module signing is required (such as many Secure Boot policies) and scenarios where it isn't (such as booting the same kernel on a legacy BIOS system). This requires

[PATCH V3] Allow configuring whether unsigned modules taint the kernel

Distributions build kernels that are intended to satisfy multiple use-cases. One is that kernels must be usable in scenarios where module signing is required (such as many Secure Boot policies) and scenarios where it isn't (such as booting the same kernel on a legacy BIOS system). This requires

[PATCH 7/7] platform/x86: fujitsu-laptop: Introduce fext_*() helper functions

Stop invoking call_fext_func() directly to improve code clarity and save some horizontal space. Signed-off-by: Michał Kępień --- drivers/platform/x86/fujitsu-laptop.c | 116 +- 1 file changed, 59 insertions(+), 57 deletions(-) diff --git

[PATCH 7/7] platform/x86: fujitsu-laptop: Introduce fext_*() helper functions

Stop invoking call_fext_func() directly to improve code clarity and save some horizontal space. Signed-off-by: Michał Kępień --- drivers/platform/x86/fujitsu-laptop.c | 116 +- 1 file changed, 59 insertions(+), 57 deletions(-) diff --git

[PATCH 5/7] platform/x86: fujitsu-laptop: Tweak how constants are commented and laid out

Update comments used for each group of constants to better reflect their current purpose. Ensure the layout of groups of constants follows the order in which call_fext_func() takes its arguments. Use alphabetic ordering for groups of constants. Signed-off-by: Michał Kępień

[PATCH 2/7] platform/x86: fujitsu-laptop: Define constants for FUNC features

Various functions exposed by the firmware through the FUNC interface allow operations to be performed on certain features. Make sure these features are referred to by consistently named constants instead of integers in order to better convey the intent of each call_fext_func() invocation.

[PATCH 5/7] platform/x86: fujitsu-laptop: Tweak how constants are commented and laid out

Update comments used for each group of constants to better reflect their current purpose. Ensure the layout of groups of constants follows the order in which call_fext_func() takes its arguments. Use alphabetic ordering for groups of constants. Signed-off-by: Michał Kępień ---

[PATCH 2/7] platform/x86: fujitsu-laptop: Define constants for FUNC features

Various functions exposed by the firmware through the FUNC interface allow operations to be performed on certain features. Make sure these features are referred to by consistently named constants instead of integers in order to better convey the intent of each call_fext_func() invocation.

[PATCH 6/7] platform/x86: fujitsu-laptop: More accurately represent the hotkey ring buffer managed by firmware

The MAX_HOTKEY_RINGBUFFER_SIZE constant is set to 100, which allows up to 100 hotkey events to be drained from the firmware ring buffer upon module load. However, no known firmware is capable of holding more than 16 hotkey events in its internal ring buffer: Method (SIRB, 1, NotSerialized)

[PATCH 6/7] platform/x86: fujitsu-laptop: More accurately represent the hotkey ring buffer managed by firmware

The MAX_HOTKEY_RINGBUFFER_SIZE constant is set to 100, which allows up to 100 hotkey events to be drained from the firmware ring buffer upon module load. However, no known firmware is capable of holding more than 16 hotkey events in its internal ring buffer: Method (SIRB, 1, NotSerialized)

Re: [PATCH V2] Allow configuring whether unsigned modules taint the kernel

On Tue, Feb 20, 2018 at 2:51 PM Matthew Garrett wrote: > Distributions build kernels that are intended to satisfy multiple > use-cases. One is that kernels must be usable in scenarios where module > signing is required (such as many Secure Boot policies) and scenarios > where

Re: [PATCH V2] Allow configuring whether unsigned modules taint the kernel

On Tue, Feb 20, 2018 at 2:51 PM Matthew Garrett wrote: > Distributions build kernels that are intended to satisfy multiple > use-cases. One is that kernels must be usable in scenarios where module > signing is required (such as many Secure Boot policies) and scenarios > where it isn't (such as

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

On Tue, 27 Feb 2018 20:24:43 + Przemyslaw Sroka wrote: > > > SETDASA is simply faster than ENTDAA, but only if there is no > > > need to collect BCR/DCR/PID of such devices. I think most > > > applications would like to have them as an status information so > > > after

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

On Tue, 27 Feb 2018 20:24:43 + Przemyslaw Sroka wrote: > > > SETDASA is simply faster than ENTDAA, but only if there is no > > > need to collect BCR/DCR/PID of such devices. I think most > > > applications would like to have them as an status information so > > > after all ENTDAA can be

Re: ftrace: Proposal for an Alternative RecordMcount framework

On Tue, 27 Feb 2018 18:04:26 +0800 Alan Kao wrote: > 1. During the final linking stages, do "objdump vmlinux.o | grep ..." [2] Note, doing it at that stage takes the longest time. It makes small changes much longer to compile. That said... > 2. Form the output as an ELF

Re: ftrace: Proposal for an Alternative RecordMcount framework

On Tue, 27 Feb 2018 18:04:26 +0800 Alan Kao wrote: > 1. During the final linking stages, do "objdump vmlinux.o | grep ..." [2] Note, doing it at that stage takes the longest time. It makes small changes much longer to compile. That said... > 2. Form the output as an ELF objecj > 3. Link the

Re: [PATCH RFC] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On Tue, Feb 27, 2018 at 9:52 PM, Andy Shevchenko wrote: > On Tue, Feb 27, 2018 at 9:32 PM, Miguel Ojeda > wrote: >> The current version is not parsing multiple x/y commands as the code >> originally intended. On top of that, kstrtoul()

Re: [PATCH RFC] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On Tue, Feb 27, 2018 at 9:52 PM, Andy Shevchenko wrote: > On Tue, Feb 27, 2018 at 9:32 PM, Miguel Ojeda > wrote: >> The current version is not parsing multiple x/y commands as the code >> originally intended. On top of that, kstrtoul() expects >> NULL-terminated strings. Finally, the code had to

Re: [PATCH v2 1/5] sysctl: Add kdoc comments to do_proc_do{u}intvec_minmax_conv_param

On Tue, Feb 27, 2018 at 03:49:47PM -0500, Waiman Long wrote: > +/** > + * DOC: do_proc_dointvec_minmax_conv_param > + * > + * The do_proc_dointvec_minmax_conv_param structure provides the > + * minimum and maximum values for doing range checking for those sysctl > + * parameters that use the

Re: [PATCH v2 1/5] sysctl: Add kdoc comments to do_proc_do{u}intvec_minmax_conv_param

On Tue, Feb 27, 2018 at 03:49:47PM -0500, Waiman Long wrote: > +/** > + * DOC: do_proc_dointvec_minmax_conv_param > + * > + * The do_proc_dointvec_minmax_conv_param structure provides the > + * minimum and maximum values for doing range checking for those sysctl > + * parameters that use the

Re: [PATCH 1/3] leaking_addresses: skip all /proc/PID except /proc/1

On Tue, Feb 27, 2018 at 09:15:03AM +0200, Alexander Kapshuk wrote: > On Tue, Feb 27, 2018 at 6:45 AM, Tobin C. Harding wrote: > > When the system is idle it is likely that most files under /proc/PID > > will be identical for various processes. Scanning _all_ the PIDs under > >

Re: [PATCH 1/3] leaking_addresses: skip all /proc/PID except /proc/1

On Tue, Feb 27, 2018 at 09:15:03AM +0200, Alexander Kapshuk wrote: > On Tue, Feb 27, 2018 at 6:45 AM, Tobin C. Harding wrote: > > When the system is idle it is likely that most files under /proc/PID > > will be identical for various processes. Scanning _all_ the PIDs under > > /proc is

Re: [PATCH v3 5/8] MIPS: mscc: add ocelot dtsi

On 16 January 2018 at 11:12, Alexandre Belloni wrote: > Add a device tree include file for the Microsemi Ocelot SoC. > > Signed-off-by: Alexandre Belloni > --- > arch/mips/boot/dts/Makefile | 1 + >

Re: [PATCH v3 5/8] MIPS: mscc: add ocelot dtsi

On 16 January 2018 at 11:12, Alexandre Belloni wrote: > Add a device tree include file for the Microsemi Ocelot SoC. > > Signed-off-by: Alexandre Belloni > --- > arch/mips/boot/dts/Makefile | 1 + > arch/mips/boot/dts/mscc/Makefile| 4 ++ > arch/mips/boot/dts/mscc/ocelot.dtsi |

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

Hi Thomas, On 2/20/2018 9:15 AM, Thomas Gleixner wrote: > Let's look at the existing crtl/mon groups which are each represented by a > directory already. > > - Adding a 'size' file to the ctrl groups would be a natural extension >which makes sense for regular cache allocations as well. >

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

Hi Thomas, On 2/20/2018 9:15 AM, Thomas Gleixner wrote: > Let's look at the existing crtl/mon groups which are each represented by a > directory already. > > - Adding a 'size' file to the ctrl groups would be a natural extension >which makes sense for regular cache allocations as well. >

Re: [PATCH RFC] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On Tue, Feb 27, 2018 at 9:13 PM, Willy Tarreau wrote: > On Tue, Feb 27, 2018 at 08:32:21PM +0100, Miguel Ojeda wrote: >> The current version is not parsing multiple x/y commands as the code >> originally intended. On top of that, kstrtoul() expects >> NULL-terminated strings.

Re: [PATCH RFC] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On Tue, Feb 27, 2018 at 9:13 PM, Willy Tarreau wrote: > On Tue, Feb 27, 2018 at 08:32:21PM +0100, Miguel Ojeda wrote: >> The current version is not parsing multiple x/y commands as the code >> originally intended. On top of that, kstrtoul() expects >> NULL-terminated strings. Finally, the code

Re: [PATCH v2 3/3] objtool: use global host flags for compilation

2018-02-27, Josh Poimboeuf: > On Mon, Feb 26, 2018 at 07:41:48PM +0100, Robin Jarry wrote: [snip] > > ifdef CONFIG_STACK_VALIDATION > >has_libelf := $(call try-run,\ > > - echo "int main() {}" | $(HOSTCC) -xc -o /dev/null -lelf -,1,0) > > + echo "int main() {}" | $(HOSTCC)

Re: [PATCH v2 3/3] objtool: use global host flags for compilation

2018-02-27, Josh Poimboeuf: > On Mon, Feb 26, 2018 at 07:41:48PM +0100, Robin Jarry wrote: [snip] > > ifdef CONFIG_STACK_VALIDATION > >has_libelf := $(call try-run,\ > > - echo "int main() {}" | $(HOSTCC) -xc -o /dev/null -lelf -,1,0) > > + echo "int main() {}" | $(HOSTCC)

Re: [RFC PATCH] Randomization of address chosen by mmap.

On Tue, Feb 27, 2018 at 5:13 AM, Ilya Smith wrote: > This is more proof of concept. Current implementation doesn't randomize > address returned by mmap. All the entropy ends with choosing mmap_base_addr > at the process creation. After that mmap build very predictable layout

Re: [RFC PATCH] Randomization of address chosen by mmap.

On Tue, Feb 27, 2018 at 5:13 AM, Ilya Smith wrote: > This is more proof of concept. Current implementation doesn't randomize > address returned by mmap. All the entropy ends with choosing mmap_base_addr > at the process creation. After that mmap build very predictable layout > of address space.

Re: [PATCH RFC] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On Tue, Feb 27, 2018 at 9:32 PM, Miguel Ojeda wrote: > The current version is not parsing multiple x/y commands as the code > originally intended. On top of that, kstrtoul() expects > NULL-terminated strings. Finally, the code had to do two passes over > the

Re: [PATCH RFC] auxdisplay: charlcd: Fix and clean up handling of x/y commands

On Tue, Feb 27, 2018 at 9:32 PM, Miguel Ojeda wrote: > The current version is not parsing multiple x/y commands as the code > originally intended. On top of that, kstrtoul() expects > NULL-terminated strings. Finally, the code had to do two passes over > the string, while now only one is done. >

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

2018-02-27, Josh Poimboeuf: > In Documentation/kbuild/kbuild.txt, we have the following environment > variables: > > KCFLAGS > -- > Additional options to the C compiler (for built-in and modules). > > CFLAGS_KERNEL >

Re: [PATCH v2 0/3] kbuild: fix host progs build with libs in non standard locations

2018-02-27, Josh Poimboeuf: > In Documentation/kbuild/kbuild.txt, we have the following environment > variables: > > KCFLAGS > -- > Additional options to the C compiler (for built-in and modules). > > CFLAGS_KERNEL >

[PATCH v2 3/5] sysctl: Warn when a clamped sysctl parameter is set out of range

Even with clamped sysctl parameters, it is still not that straight forward to figure out the exact range of those parameters. One may try to write extreme parameter values to see if they get clamped. To make it easier, a warning with the expected range will now be printed in the kernel ring buffer

[PATCH v2 3/5] sysctl: Warn when a clamped sysctl parameter is set out of range

Even with clamped sysctl parameters, it is still not that straight forward to figure out the exact range of those parameters. One may try to write extreme parameter values to see if they get clamped. To make it easier, a warning with the expected range will now be printed in the kernel ring buffer

[PATCH v2 4/5] ipc: Clamp msgmni and shmmni to the real IPCMNI limit

A user can write arbitrary integer values to msgmni and shmmni sysctl parameters without getting error, but the actual limit is really IPCMNI (32k). This can mislead users as they think they can get a value that is not real. Enforcing the limit by failing the sysctl parameter write, however, can

[PATCH v2 4/5] ipc: Clamp msgmni and shmmni to the real IPCMNI limit

A user can write arbitrary integer values to msgmni and shmmni sysctl parameters without getting error, but the actual limit is really IPCMNI (32k). This can mislead users as they think they can get a value that is not real. Enforcing the limit by failing the sysctl parameter write, however, can

[PATCH v2 0/5] ipc: Clamp *mni to the real IPCMNI limit

v1->v2: - Add kdoc comments to the do_proc_do{u}intvec_minmax_conv_param structures. - Add a new flags field to the ctl_table structure for specifying whether range clamping should be activated instead of adding new sysctl parameter handlers. - Clamp the semmni value embedded in the

[PATCH v2 0/5] ipc: Clamp *mni to the real IPCMNI limit

v1->v2: - Add kdoc comments to the do_proc_do{u}intvec_minmax_conv_param structures. - Add a new flags field to the ctl_table structure for specifying whether range clamping should be activated instead of adding new sysctl parameter handlers. - Clamp the semmni value embedded in the

[PATCH v2 5/5] ipc: Clamp semmni to the real IPCMNI limit

This patch clamps the semmni value (fourth element of sem_ctls[] array) to within the [0, IPCMNI] range and prints a warning message once when an out-of-range value is being written. Signed-off-by: Waiman Long --- ipc/ipc_sysctl.c | 13 - ipc/sem.c| 33

[PATCH v2 5/5] ipc: Clamp semmni to the real IPCMNI limit

This patch clamps the semmni value (fourth element of sem_ctls[] array) to within the [0, IPCMNI] range and prints a warning message once when an out-of-range value is being written. Signed-off-by: Waiman Long --- ipc/ipc_sysctl.c | 13 - ipc/sem.c| 33

[PATCH v2 1/5] sysctl: Add kdoc comments to do_proc_do{u}intvec_minmax_conv_param

Kdoc comments are added to the do_proc_dointvec_minmax_conv_param and do_proc_douintvec_minmax_conv_param structures thare are used internally for range checking. Signed-off-by: Waiman Long --- kernel/sysctl.c | 22 ++ 1 file changed, 22 insertions(+)

[PATCH v2 1/5] sysctl: Add kdoc comments to do_proc_do{u}intvec_minmax_conv_param

Kdoc comments are added to the do_proc_dointvec_minmax_conv_param and do_proc_douintvec_minmax_conv_param structures thare are used internally for range checking. Signed-off-by: Waiman Long --- kernel/sysctl.c | 22 ++ 1 file changed, 22 insertions(+) diff --git

[PATCH v2 2/5] sysctl: Add flags to support min/max range clamping

When minimum/maximum values are specified for a sysctl parameter in the ctl_table structure with proc_dointvec_minmax() handler, update to that parameter will fail with error if the given value is outside of the required range. There are use cases where it may be better to clamp the value of the

[PATCH v2 2/5] sysctl: Add flags to support min/max range clamping

When minimum/maximum values are specified for a sysctl parameter in the ctl_table structure with proc_dointvec_minmax() handler, update to that parameter will fail with error if the given value is outside of the required range. There are use cases where it may be better to clamp the value of the

[PATCH] arm64: dts: rockchip: Fix rk3399-gru-* s2r (pinctrl hogs, wifi reset)

Back in the early days when gru devices were still under development we found an issue where the WiFi reset line needed to be configured as early as possible during the boot process to avoid the WiFi module being in a bad state. We found that the way to get the kernel to do this in the earliest

[PATCH] arm64: dts: rockchip: Fix rk3399-gru-* s2r (pinctrl hogs, wifi reset)

Back in the early days when gru devices were still under development we found an issue where the WiFi reset line needed to be configured as early as possible during the boot process to avoid the WiFi module being in a bad state. We found that the way to get the kernel to do this in the earliest

[PATCH] ARM: dts: NSP: Switch to port 8 for CPU port

Now that we have added support for pre-pended Broadcom tags with commit 11606039604c ("net: dsa: b53: Support prepended Broadcom tags") we can switch all the Northstar Plus reference boards to use port 8 for the CPU port. This allows us to prepare room for supporting the Flow Accelerator 2 NAPT

[PATCH] ARM: dts: NSP: Switch to port 8 for CPU port

Now that we have added support for pre-pended Broadcom tags with commit 11606039604c ("net: dsa: b53: Support prepended Broadcom tags") we can switch all the Northstar Plus reference boards to use port 8 for the CPU port. This allows us to prepare room for supporting the Flow Accelerator 2 NAPT

Re: [PATCH 01/21] powerpc: Remove warning on array size when empty

On Tue, Feb 27, 2018 at 05:52:06PM +0200, Andy Shevchenko wrote: > On Tue, Feb 27, 2018 at 9:44 AM, Mathieu Malaterre wrote: > > On Tue, Feb 27, 2018 at 8:33 AM, Christophe LEROY > > wrote: > > > Much simpler is just add > > > > if

Re: [PATCH 01/21] powerpc: Remove warning on array size when empty

On Tue, Feb 27, 2018 at 05:52:06PM +0200, Andy Shevchenko wrote: > On Tue, Feb 27, 2018 at 9:44 AM, Mathieu Malaterre wrote: > > On Tue, Feb 27, 2018 at 8:33 AM, Christophe LEROY > > wrote: > > > Much simpler is just add > > > > if (ARRAY_SIZE() == 0) > > return; > > >> Or

[PATCH 0/1] Re: Applied "ASoC: topology: Fix logical inversion in set_link_hw_format()" to the asoc tree

Hello Mark, Pierre-Louis, Pan, Liam, As there are too much open questions regarding the bclk and fsync inversion in set_link_hw_format(), I would like to suggest the alternative solution. This solution will fit both use-cases: * existing use-cases (Broadwell, etc.) * new use-cases (Sound Open

[PATCH 0/1] Re: Applied "ASoC: topology: Fix logical inversion in set_link_hw_format()" to the asoc tree

Hello Mark, Pierre-Louis, Pan, Liam, As there are too much open questions regarding the bclk and fsync inversion in set_link_hw_format(), I would like to suggest the alternative solution. This solution will fit both use-cases: * existing use-cases (Broadwell, etc.) * new use-cases (Sound Open

[PATCH 1/1] ASoC: topology: Fix bclk and fsync inversion in set_link_hw_format()

The values of bclk and fsync are inverted WRT the codec. But the existing solution already works for Broadwell, see the alsa-lib config: `alsa-lib/src/conf/topology/broadwell/broadwell.conf` This commit provides the backwards-compatible solution to fix this misuse. This commit goes in pair with

[PATCH 1/1] ASoC: topology: Fix bclk and fsync inversion in set_link_hw_format()

The values of bclk and fsync are inverted WRT the codec. But the existing solution already works for Broadwell, see the alsa-lib config: `alsa-lib/src/conf/topology/broadwell/broadwell.conf` This commit provides the backwards-compatible solution to fix this misuse. This commit goes in pair with

<    4   5   6   7   8   9   10   11   12   13   >