Re: [Ksummit-discuss] bug-introducing patches

On Sat, Jul 14, 2018 at 11:09:13PM +0200, Pavel Machek wrote: > > For anyone interested in making sure that obscure (whatever that means) > > drivers are tested for stable releases, but does not want to spend time on > > it, > > all I can recommend is to implement qemu support for it and let me

Re: [Ksummit-discuss] bug-introducing patches

On Sat, Jul 14, 2018 at 11:09:13PM +0200, Pavel Machek wrote: > > For anyone interested in making sure that obscure (whatever that means) > > drivers are tested for stable releases, but does not want to spend time on > > it, > > all I can recommend is to implement qemu support for it and let me

Re: [PATCH v5 6/7] Bluetooth: mediatek: Add protocol support for MediaTek serial devices

On Sat, 2018-07-14 at 18:32 +0200, Marcel Holtmann wrote: > Hi Sean, > > > This adds a driver to run on the top of btuart driver for the MediaTek > > serial protocol based on running H:4, which can enable the built-in > > Bluetooth device inside MT7622 SoC. > > > > Signed-off-by: Sean Wang > >

Re: [PATCH v5 6/7] Bluetooth: mediatek: Add protocol support for MediaTek serial devices

On Sat, 2018-07-14 at 18:32 +0200, Marcel Holtmann wrote: > Hi Sean, > > > This adds a driver to run on the top of btuart driver for the MediaTek > > serial protocol based on running H:4, which can enable the built-in > > Bluetooth device inside MT7622 SoC. > > > > Signed-off-by: Sean Wang > >

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

On Sun, Jul 15, 2018 at 12:25 PM, Shakeel Butt wrote: > On Sat, Jul 14, 2018 at 7:10 PM Yafang Shao wrote: >> >> On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt wrote: >> > On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao wrote: >> >> >> >> try_charge maybe executed in packet receive path, which is

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

On Sun, Jul 15, 2018 at 12:25 PM, Shakeel Butt wrote: > On Sat, Jul 14, 2018 at 7:10 PM Yafang Shao wrote: >> >> On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt wrote: >> > On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao wrote: >> >> >> >> try_charge maybe executed in packet receive path, which is

Re: [PATCH v5 1/7] dt-bindings: net: bluetooth: Add mediatek-bluetooth

On Sat, 2018-07-14 at 18:26 +0200, Marcel Holtmann wrote: > Hi Sean, > > > Add binding document for a SoC built-in device using MediaTek protocol. > > Which could be found on MT7622 SoC or other similar MediaTek SoCs. > > > > Signed-off-by: Sean Wang > > Reviewed-by: Rob Herring > > --- > >

Re: [PATCH v5 1/7] dt-bindings: net: bluetooth: Add mediatek-bluetooth

On Sat, 2018-07-14 at 18:26 +0200, Marcel Holtmann wrote: > Hi Sean, > > > Add binding document for a SoC built-in device using MediaTek protocol. > > Which could be found on MT7622 SoC or other similar MediaTek SoCs. > > > > Signed-off-by: Sean Wang > > Reviewed-by: Rob Herring > > --- > >

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

On Sat, Jul 14, 2018 at 7:10 PM Yafang Shao wrote: > > On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt wrote: > > On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao wrote: > >> > >> try_charge maybe executed in packet receive path, which is in interrupt > >> context. > >> In this situation, the

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

On Sat, Jul 14, 2018 at 7:10 PM Yafang Shao wrote: > > On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt wrote: > > On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao wrote: > >> > >> try_charge maybe executed in packet receive path, which is in interrupt > >> context. > >> In this situation, the

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

On Sat, 2018-07-14 at 18:59 -0700, Linus Torvalds wrote: > On Sat, Jul 14, 2018 at 6:57 PM Linus Torvalds > wrote: > > Honestly, I'd like to just encourage people to get the sparse update > > from Luc Van Oostenryck instead. > > > > For a while there it looked like Chris Li would just pull from

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

On Sat, 2018-07-14 at 18:59 -0700, Linus Torvalds wrote: > On Sat, Jul 14, 2018 at 6:57 PM Linus Torvalds > wrote: > > Honestly, I'd like to just encourage people to get the sparse update > > from Luc Van Oostenryck instead. > > > > For a while there it looked like Chris Li would just pull from

[PATCH] arm64: cpuinfo: Include cleartext implementer and part strings

There's some use in printing out what the implementer and part numbers decode to for cases where they're known. I filled in the table based on public information; mostly from ARM TRMs and other tools (and some of the SSBD tables in the kernel, etc). Apple IDs came from

[PATCH] arm64: cpuinfo: Include cleartext implementer and part strings

There's some use in printing out what the implementer and part numbers decode to for cases where they're known. I filled in the table based on public information; mostly from ARM TRMs and other tools (and some of the SSBD tables in the kernel, etc). Apple IDs came from

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

On Sat, 2018-07-14 at 18:59 -0700, Linus Torvalds wrote: > On Sat, Jul 14, 2018 at 6:57 PM Linus Torvalds > wrote: > > > > Honestly, I'd like to just encourage people to get the sparse update > > from Luc Van Oostenryck instead. > > > > For a while there it looked like Chris Li would just pull

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

On Sat, 2018-07-14 at 18:59 -0700, Linus Torvalds wrote: > On Sat, Jul 14, 2018 at 6:57 PM Linus Torvalds > wrote: > > > > Honestly, I'd like to just encourage people to get the sparse update > > from Luc Van Oostenryck instead. > > > > For a while there it looked like Chris Li would just pull

[PATCH] x86/boot: Fix if_changed build flip/flop

The if_changed kbuild function can only be used once per target. If not it will effectively always trigger, flipping back and forth between the two commands getting recorded. Instead, merge the two commands into a single function to get stable build artifacts (i.e. .vmlinux.cmd). Reported-by:

[PATCH] x86/boot: Fix if_changed build flip/flop

The if_changed kbuild function can only be used once per target. If not it will effectively always trigger, flipping back and forth between the two commands getting recorded. Instead, merge the two commands into a single function to get stable build artifacts (i.e. .vmlinux.cmd). Reported-by:

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

On Sun, Jul 15, 2018 at 10:10 AM, Yafang Shao wrote: > On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt wrote: >> On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao wrote: >>> >>> try_charge maybe executed in packet receive path, which is in interrupt >>> context. >>> In this situation, the 'current' is

Re: [PATCH 1/1] f2fs: checkpoint disabling

On 07/11, Daniel Rosenberg wrote: > This adds a lightweight non-persistent snapshotting scheme to f2fs. > > To use, mount with the option checkpoint=disable, and to return to > normal operation, remount with checkpoint=enable. If the filesystem > is shut down before remounting with

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

On Sun, Jul 15, 2018 at 10:10 AM, Yafang Shao wrote: > On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt wrote: >> On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao wrote: >>> >>> try_charge maybe executed in packet receive path, which is in interrupt >>> context. >>> In this situation, the 'current' is

Re: [PATCH 1/1] f2fs: checkpoint disabling

On 07/11, Daniel Rosenberg wrote: > This adds a lightweight non-persistent snapshotting scheme to f2fs. > > To use, mount with the option checkpoint=disable, and to return to > normal operation, remount with checkpoint=enable. If the filesystem > is shut down before remounting with

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt wrote: > On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao wrote: >> >> try_charge maybe executed in packet receive path, which is in interrupt >> context. >> In this situation, the 'current' is the interrupted task, which may has >> no relation to the rx

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt wrote: > On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao wrote: >> >> try_charge maybe executed in packet receive path, which is in interrupt >> context. >> In this situation, the 'current' is the interrupted task, which may has >> no relation to the rx

Re: [PATCH v7] add param that allows bootline control of hardened usercopy

On Wed, Jul 4, 2018 at 10:47 AM, Vlastimil Babka wrote: > On 07/04/2018 06:52 PM, Kees Cook wrote: >> This produces less efficient code in the general case, and I'd like to >> keep the general case (hardening enabled) as fast as possible. > > How specifically is the code less efficient? It should

Re: [PATCH v7] add param that allows bootline control of hardened usercopy

On Wed, Jul 4, 2018 at 10:47 AM, Vlastimil Babka wrote: > On 07/04/2018 06:52 PM, Kees Cook wrote: >> This produces less efficient code in the general case, and I'd like to >> keep the general case (hardening enabled) as fast as possible. > > How specifically is the code less efficient? It should

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

Oh, and I meant to cc Luc on that email, but then forgot. So here he is cc'd now. Linus On Sat, Jul 14, 2018 at 6:57 PM Linus Torvalds wrote: > > Honestly, I'd like to just encourage people to get the sparse update > from Luc Van Oostenryck instead. > > For a while there it looked

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

Oh, and I meant to cc Luc on that email, but then forgot. So here he is cc'd now. Linus On Sat, Jul 14, 2018 at 6:57 PM Linus Torvalds wrote: > > Honestly, I'd like to just encourage people to get the sparse update > from Luc Van Oostenryck instead. > > For a while there it looked

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

On Sat, Jul 14, 2018 at 6:49 PM Kees Cook wrote: > > I'm fine with this; it'll only activate for sparse. I'd like to get > Linus's eyes on it, though, since this macro caused us SO much pain > that I'm nervous to change it without some greater level of review. :) Honestly, I'd like to just

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

On Sat, Jul 14, 2018 at 6:49 PM Kees Cook wrote: > > I'm fine with this; it'll only activate for sparse. I'd like to get > Linus's eyes on it, though, since this macro caused us SO much pain > that I'm nervous to change it without some greater level of review. :) Honestly, I'd like to just

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

On Thu, Jul 5, 2018 at 9:17 AM, Bart Van Assche wrote: > The macro __is_constexpr() causes sparse to report the following: > > warning: expression using sizeof(void) > > Avoid this by using __builtin_constant_p() instead. > > Fixes: 3c8ba0d61d04 ("kernel.h: Retain constant expression output

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

On Thu, Jul 5, 2018 at 9:17 AM, Bart Van Assche wrote: > The macro __is_constexpr() causes sparse to report the following: > > warning: expression using sizeof(void) > > Avoid this by using __builtin_constant_p() instead. > > Fixes: 3c8ba0d61d04 ("kernel.h: Retain constant expression output

Re: [PATCH v13 2/2] Add oom victim's memcg to the oom context information

Hi David Could I use use plain old %d? Just like this, pr_cont(",task=%s,pid=%d,uid=%d\n", p->comm, p->pid, from_kuid(_user_ns, task_uid(p))); Thanks

Re: [PATCH v13 2/2] Add oom victim's memcg to the oom context information

Hi David Could I use use plain old %d? Just like this, pr_cont(",task=%s,pid=%d,uid=%d\n", p->comm, p->pid, from_kuid(_user_ns, task_uid(p))); Thanks

[PATCH] RISC-V: Don't increment sepc after breakpoint.

Adding 4 to sepc is pointless, and is wrong if we executed a 2-byte compressed breakpoint. This plus a corresponding gdb patch allows compressed breakpoints to work in gdb. Gdb maintainers have already agreed that this is the right approach. Signed-off-by: Jim Wilson ---

[PATCH] RISC-V: Don't increment sepc after breakpoint.

Adding 4 to sepc is pointless, and is wrong if we executed a 2-byte compressed breakpoint. This plus a corresponding gdb patch allows compressed breakpoints to work in gdb. Gdb maintainers have already agreed that this is the right approach. Signed-off-by: Jim Wilson ---

Applied "ASoC: allow soc-core to pick up name prefixes from component nodes" to the asoc tree

The patch ASoC: allow soc-core to pick up name prefixes from component nodes has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Re: [PATCH] base: core: Remove WARN_ON from link dependencies check

On Thu, Jul 12, 2018 at 10:06:23AM +0200, Benjamin Gaignard wrote: > In some cases the link between between customer and supplier > already exist. Do not warn about already existing dependencies > because device_link_add() take care of this case. Reviwed-by: Mark Brown signature.asc

Re: [PATCH] base: core: Remove WARN_ON from link dependencies check

On Thu, Jul 12, 2018 at 10:06:23AM +0200, Benjamin Gaignard wrote: > In some cases the link between between customer and supplier > already exist. Do not warn about already existing dependencies > because device_link_add() take care of this case. Reviwed-by: Mark Brown signature.asc

Applied "ASoC: allow soc-core to pick up name prefixes from component nodes" to the asoc tree

The patch ASoC: allow soc-core to pick up name prefixes from component nodes has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "ASoC: trace: remove snd_soc_codec" to the asoc tree

The patch ASoC: trace: remove snd_soc_codec has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: trace: remove snd_soc_codec" to the asoc tree

The patch ASoC: trace: remove snd_soc_codec has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: add DT documentation for the sound-name-prefix property" to the asoc tree

The patch ASoC: add DT documentation for the sound-name-prefix property has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: add DT documentation for the sound-name-prefix property" to the asoc tree

The patch ASoC: add DT documentation for the sound-name-prefix property has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Re: [PATCH] regulator: core: fix _regulator_do_disable return value

On Fri, Jul 13, 2018 at 05:48:54PM +0200, Marco Felsch wrote: > On 18-07-13 14:07, Mark Brown wrote: > > This is fine - consumers shouldn't expect that a disable will cause > > anything to actually get powered off, constraints or other consumers > > might mean that the disable doesn't actually

Re: [PATCH v2 1/3] dt-bindings: pfuze100: add optional disable switch-regulators binding

On Fri, Jul 13, 2018 at 02:50:01PM +0200, Marco Felsch wrote: > +Optional properties: > +- fsl,pfuze-support-disable: Boolean, if present disable all unused switch > + regulators to save power consumption. Attention, till 4.18 these regulators The property name sounds like it affects all the

Re: [PATCH] regulator: core: fix _regulator_do_disable return value

On Fri, Jul 13, 2018 at 05:48:54PM +0200, Marco Felsch wrote: > On 18-07-13 14:07, Mark Brown wrote: > > This is fine - consumers shouldn't expect that a disable will cause > > anything to actually get powered off, constraints or other consumers > > might mean that the disable doesn't actually

Re: [PATCH v2 1/3] dt-bindings: pfuze100: add optional disable switch-regulators binding

On Fri, Jul 13, 2018 at 02:50:01PM +0200, Marco Felsch wrote: > +Optional properties: > +- fsl,pfuze-support-disable: Boolean, if present disable all unused switch > + regulators to save power consumption. Attention, till 4.18 these regulators The property name sounds like it affects all the

[PATCH] ACPI: battery: remove redundant old_present check on insertion

From: Lucas Rangit Magasweran On removal battery_present changes from 1 to 0 after calling acpi_battery_get_statu() and battery->update_time is set to 0 before returning. On insertion battery_present changes from 0 to 1 after calling acpi_battery_get_status() and acpi_battery_get_info() is

[PATCH] ACPI: battery: remove redundant old_present check on insertion

From: Lucas Rangit Magasweran On removal battery_present changes from 1 to 0 after calling acpi_battery_get_statu() and battery->update_time is set to 0 before returning. On insertion battery_present changes from 0 to 1 after calling acpi_battery_get_status() and acpi_battery_get_info() is

Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

On Sun 2018-07-15 00:29:25, Pavel Machek wrote: > On Sun 2018-07-15 00:02:57, Jacek Anaszewski wrote: > > Hi Pavel, > > > > On 07/14/2018 11:20 PM, Pavel Machek wrote: > > >Hi! > > > > > >>>It also drew my attention to the issue of desired pattern sysfs > > >>>interface semantics on uninitialized

[PATCH] ACPI: battery: use cache_time as cache "enabled"

From: Lucas Rangit Magasweran When battery state is not cached the module parameter cache_time is 0 and battery->update_time starts at 0. However, it set to jiffies in each call to acpi_battery_get_state() and should not be used to determine if a cache time is used. Using battery->update_time

Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

On Sun 2018-07-15 00:29:25, Pavel Machek wrote: > On Sun 2018-07-15 00:02:57, Jacek Anaszewski wrote: > > Hi Pavel, > > > > On 07/14/2018 11:20 PM, Pavel Machek wrote: > > >Hi! > > > > > >>>It also drew my attention to the issue of desired pattern sysfs > > >>>interface semantics on uninitialized

[PATCH] ACPI: battery: use cache_time as cache "enabled"

From: Lucas Rangit Magasweran When battery state is not cached the module parameter cache_time is 0 and battery->update_time starts at 0. However, it set to jiffies in each call to acpi_battery_get_state() and should not be used to determine if a cache time is used. Using battery->update_time

[PATCH 2/2] staging: olpc_dcon: add missing identifier names

Add missing function argument identifier names as suggested by checkpatch.pl. Signed-off-by: Cristian Kubis --- drivers/staging/olpc_dcon/olpc_dcon.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/olpc_dcon/olpc_dcon.h

[PATCH 1/2] staging: olpc_dcon: prefer 'help' in KConfig

Fix for a style warning reported by checkpatch.pl in KConfig suggesting to use 'help' instead of '---help---'. Signed-off-by: Cristian Kubis --- drivers/staging/olpc_dcon/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/olpc_dcon/Kconfig

[PATCH 0/2] staging: olpc_dcon: fix style warnings

Series of patches fixing two different kinds of style warnings in olpc_dcon as reported by checkpatch.pl. Cristian Kubis (2): staging: olpc_dcon: prefer 'help' in KConfig staging: olpc_dcon: add missing identifier names drivers/staging/olpc_dcon/Kconfig | 6 +++---

[PATCH 2/2] staging: olpc_dcon: add missing identifier names

Add missing function argument identifier names as suggested by checkpatch.pl. Signed-off-by: Cristian Kubis --- drivers/staging/olpc_dcon/olpc_dcon.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/olpc_dcon/olpc_dcon.h

[PATCH 1/2] staging: olpc_dcon: prefer 'help' in KConfig

Fix for a style warning reported by checkpatch.pl in KConfig suggesting to use 'help' instead of '---help---'. Signed-off-by: Cristian Kubis --- drivers/staging/olpc_dcon/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/olpc_dcon/Kconfig

[PATCH 0/2] staging: olpc_dcon: fix style warnings

Series of patches fixing two different kinds of style warnings in olpc_dcon as reported by checkpatch.pl. Cristian Kubis (2): staging: olpc_dcon: prefer 'help' in KConfig staging: olpc_dcon: add missing identifier names drivers/staging/olpc_dcon/Kconfig | 6 +++---

Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

On Sun 2018-07-15 00:02:57, Jacek Anaszewski wrote: > Hi Pavel, > > On 07/14/2018 11:20 PM, Pavel Machek wrote: > >Hi! > > > >>>It also drew my attention to the issue of desired pattern sysfs > >>>interface semantics on uninitialized pattern. In your implementation > >>>user seems to be unable to

Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

On Sun 2018-07-15 00:02:57, Jacek Anaszewski wrote: > Hi Pavel, > > On 07/14/2018 11:20 PM, Pavel Machek wrote: > >Hi! > > > >>>It also drew my attention to the issue of desired pattern sysfs > >>>interface semantics on uninitialized pattern. In your implementation > >>>user seems to be unable to

Re: [PATCH v9 1/5] clocksource/drivers/timer-mediatek: Add system timer bindings

On 06/07/2018 01:11, Stanley Chu wrote: > This patch adds bindings of new "System Timer" on Mediatek SoCs. > > Remove RTC clock in the same time because it is not used by > both "General Purpose Timer" and "System Timer" now. > > Signed-off-by: Stanley Chu > --- I have applied the series for

Re: [PATCH v9 1/5] clocksource/drivers/timer-mediatek: Add system timer bindings

On 06/07/2018 01:11, Stanley Chu wrote: > This patch adds bindings of new "System Timer" on Mediatek SoCs. > > Remove RTC clock in the same time because it is not used by > both "General Purpose Timer" and "System Timer" now. > > Signed-off-by: Stanley Chu > --- I have applied the series for

Re: [GIT PULL 3/3] ARM: defconfig: Pull for v4.19

On Thu, Jul 12, 2018 at 06:46:39PM +0200, Krzysztof Kozlowski wrote: > Hi, > > Rebased on v4.18-rc2. > > Best regards, > Krzysztof > > > The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819: > > Linux 4.18-rc2 (2018-06-24 20:54:29 +0800) > > are available in the git

Re: [GIT PULL 3/3] ARM: defconfig: Pull for v4.19

On Thu, Jul 12, 2018 at 06:46:39PM +0200, Krzysztof Kozlowski wrote: > Hi, > > Rebased on v4.18-rc2. > > Best regards, > Krzysztof > > > The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819: > > Linux 4.18-rc2 (2018-06-24 20:54:29 +0800) > > are available in the git

Re: [GIT PULL 1/3] ARM: dts: exynos: Pull for v4.19

On Thu, Jul 12, 2018 at 06:46:40PM +0200, Krzysztof Kozlowski wrote: > Hi, > > Rebased on v4.18-rc2. > > Best regards, > Krzysztof > > > The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819: > > Linux 4.18-rc2 (2018-06-24 20:54:29 +0800) > > are available in the git

Re: [GIT PULL 2/3] arm64: dts: exynos: Pull for v4.19

On Thu, Jul 12, 2018 at 06:46:41PM +0200, Krzysztof Kozlowski wrote: > Hi, > > Rebased on v4.18-rc2. > > Best regards, > Krzysztof > > > The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819: > > Linux 4.18-rc2 (2018-06-24 20:54:29 +0800) > > are available in the git

Re: [GIT PULL 1/3] ARM: dts: exynos: Pull for v4.19

On Thu, Jul 12, 2018 at 06:46:40PM +0200, Krzysztof Kozlowski wrote: > Hi, > > Rebased on v4.18-rc2. > > Best regards, > Krzysztof > > > The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819: > > Linux 4.18-rc2 (2018-06-24 20:54:29 +0800) > > are available in the git

Re: [GIT PULL 2/3] arm64: dts: exynos: Pull for v4.19

On Thu, Jul 12, 2018 at 06:46:41PM +0200, Krzysztof Kozlowski wrote: > Hi, > > Rebased on v4.18-rc2. > > Best regards, > Krzysztof > > > The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819: > > Linux 4.18-rc2 (2018-06-24 20:54:29 +0800) > > are available in the git

Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

Hi Pavel, On 07/14/2018 11:20 PM, Pavel Machek wrote: Hi! It also drew my attention to the issue of desired pattern sysfs interface semantics on uninitialized pattern. In your implementation user seems to be unable to determine if the pattern is activated or not. We should define the

Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

Hi Pavel, On 07/14/2018 11:20 PM, Pavel Machek wrote: Hi! It also drew my attention to the issue of desired pattern sysfs interface semantics on uninitialized pattern. In your implementation user seems to be unable to determine if the pattern is activated or not. We should define the

Re: [PATCH] vme: ca91cx42: remove redundant variable i

On Sat, Jul 14, 2018 at 05:33:32PM +0100, Colin King wrote: > From: Colin Ian King > > Variable i is being assigned but is never used hence it is redundant > and can be removed. > > Cleans up clang warning: > warning: variable 'i' set but not used [-Wunused-but-set-variable] > > Signed-off-by:

Re: [PATCH] vme: ca91cx42: remove redundant variable i

On Sat, Jul 14, 2018 at 05:33:32PM +0100, Colin King wrote: > From: Colin Ian King > > Variable i is being assigned but is never used hence it is redundant > and can be removed. > > Cleans up clang warning: > warning: variable 'i' set but not used [-Wunused-but-set-variable] > > Signed-off-by:

Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

Hi! > > It also drew my attention to the issue of desired pattern sysfs > > interface semantics on uninitialized pattern. In your implementation > > user seems to be unable to determine if the pattern is activated > > or not. We should define the semantics for this use case and > > describe it in

Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

Hi! > > It also drew my attention to the issue of desired pattern sysfs > > interface semantics on uninitialized pattern. In your implementation > > user seems to be unable to determine if the pattern is activated > > or not. We should define the semantics for this use case and > > describe it in

Re: [Ksummit-discuss] bug-introducing patches

Hi! > >Well, 0day, kernelci etc... is nice... until the change is in the > >driver. Most of the kernel are drivers, remember? > > > >I don't know. I'd say that if patch is important enough for -stable, > >there should be someone testing it. For core kernel changes, that can > >be 0day bot, but

Re: [Ksummit-discuss] bug-introducing patches

Hi! > >Well, 0day, kernelci etc... is nice... until the change is in the > >driver. Most of the kernel are drivers, remember? > > > >I don't know. I'd say that if patch is important enough for -stable, > >there should be someone testing it. For core kernel changes, that can > >be 0day bot, but

[GIT PULL] RTC fixes for 4.18

Hi Linus, Here are two fixes for 4.18. The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-4.18-2 for you

[GIT PULL] RTC fixes for 4.18

Hi Linus, Here are two fixes for 4.18. The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-4.18-2 for you

Re: [Ksummit-discuss] bug-introducing patches

On 07/14/2018 12:47 PM, Pavel Machek wrote: Hi! The way I see it, if a commit can get one or two tested-by, it's a good alternative to a week in -next. Agreed. Even their own actually. And I'm not kidding. Those who run large amounts of tests on certain patches could really mention is in

Re: [Ksummit-discuss] bug-introducing patches

On 07/14/2018 12:47 PM, Pavel Machek wrote: Hi! The way I see it, if a commit can get one or two tested-by, it's a good alternative to a week in -next. Agreed. Even their own actually. And I'm not kidding. Those who run large amounts of tests on certain patches could really mention is in

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

On Sat, Jul 14, 2018 at 02:39:24PM -0500, Eric W. Biederman wrote: > Josh Triplett writes: > > > On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote: > >> For a config option that no one has come forward with an actual real > >> world use case for disabling, that cost seems much

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

On Sat, Jul 14, 2018 at 02:39:24PM -0500, Eric W. Biederman wrote: > Josh Triplett writes: > > > On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote: > >> For a config option that no one has come forward with an actual real > >> world use case for disabling, that cost seems much

Re: [PATCH 2/2] ARM: dts: pxa: add mioa701 board description

Rob Herring writes: Hi Rob, >> + /* compatible = "mitac,mioa701"; */ >> + compatible = "marvell,pxa270"; > > Why the comment? Leftover, I'll remove it. >> + pstore_region:region@0xa200 { > > Drop the 0x Done. >> + compatible

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

On Sat, Jul 14, 2018 at 02:39:24PM -0500, Eric W. Biederman wrote: > Josh Triplett writes: > > > On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote: > >> For a config option that no one has come forward with an actual real > >> world use case for disabling, that cost seems much

Re: [PATCH 2/2] ARM: dts: pxa: add mioa701 board description

Rob Herring writes: Hi Rob, >> + /* compatible = "mitac,mioa701"; */ >> + compatible = "marvell,pxa270"; > > Why the comment? Leftover, I'll remove it. >> + pstore_region:region@0xa200 { > > Drop the 0x Done. >> + compatible

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

On Sat, Jul 14, 2018 at 02:39:24PM -0500, Eric W. Biederman wrote: > Josh Triplett writes: > > > On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote: > >> For a config option that no one has come forward with an actual real > >> world use case for disabling, that cost seems much

[PATCH] x86/events/intel/ds: Fix bts_interrupt_threshold alignment

Markus reported that BTS is sporadically missing the tail of the trace in the perf_event data buffer: [decode error (1): instruction overflow] shown in GDB; and bisected it to the conversion of debug_store to PTI. A little "optimization" crept into alloc_bts_buffer(), which mistakenly placed

[PATCH] x86/events/intel/ds: Fix bts_interrupt_threshold alignment

Markus reported that BTS is sporadically missing the tail of the trace in the perf_event data buffer: [decode error (1): instruction overflow] shown in GDB; and bisected it to the conversion of debug_store to PTI. A little "optimization" crept into alloc_bts_buffer(), which mistakenly placed

Re: [PATCH 1/2] mux:adgs1408/1409: New driver for Analog Devices ADGS1408/1409 mux …

On 2018-07-14 16:02, Lars-Peter Clausen wrote: > On 07/14/2018 02:04 PM, Peter Rosin wrote: > [...] >>> +static int adgs140x_spi_reg_write(struct spi_device *spi, >>> + u8 reg_addr, u8 reg_data) >>> +{ >>> + u8 tx_buf[2]; >>> + >>> + tx_buf[0] = reg_addr; >>> +

Re: [PATCH 1/2] mux:adgs1408/1409: New driver for Analog Devices ADGS1408/1409 mux …

On 2018-07-14 16:02, Lars-Peter Clausen wrote: > On 07/14/2018 02:04 PM, Peter Rosin wrote: > [...] >>> +static int adgs140x_spi_reg_write(struct spi_device *spi, >>> + u8 reg_addr, u8 reg_data) >>> +{ >>> + u8 tx_buf[2]; >>> + >>> + tx_buf[0] = reg_addr; >>> +

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote: > For a config option that no one has come forward with an actual real > world use case for disabling, that cost seems much too high. The real-world use case is precisely as stated: code size, both storage and RAM. I regularly

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote: > For a config option that no one has come forward with an actual real > world use case for disabling, that cost seems much too high. The real-world use case is precisely as stated: code size, both storage and RAM. I regularly

Re: [Ksummit-discuss] bug-introducing patches

Hi! > >>>The way I see it, if a commit can get one or two tested-by, it's a good > >>>alternative to a week in -next. > >> > >>Agreed. Even their own actually. And I'm not kidding. Those who run large > >>amounts of tests on certain patches could really mention is in tested-by, > >>as opposed to

Re: [Ksummit-discuss] bug-introducing patches

Hi! > >>>The way I see it, if a commit can get one or two tested-by, it's a good > >>>alternative to a week in -next. > >> > >>Agreed. Even their own actually. And I'm not kidding. Those who run large > >>amounts of tests on certain patches could really mention is in tested-by, > >>as opposed to

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

Josh Triplett writes: > On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote: >> For a config option that no one has come forward with an actual real >> world use case for disabling, that cost seems much too high. > > The real-world use case is precisely as stated: code size, both

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

Josh Triplett writes: > On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote: >> For a config option that no one has come forward with an actual real >> world use case for disabling, that cost seems much too high. > > The real-world use case is precisely as stated: code size, both

Re: [PATCH 12/18] staging: gasket: annotate ioctl arg with __user

>> I think I'm following >> http://www.kroah.com/log/linux/linux-staging-update.html, >> but if I'm off in the weeds do clue me in, thanks. > > That's something I wrote 9 years ago :) Still the top search result for how to work in staging, suggest an update. :)

Re: [PATCH 12/18] staging: gasket: annotate ioctl arg with __user

>> I think I'm following >> http://www.kroah.com/log/linux/linux-staging-update.html, >> but if I'm off in the weeds do clue me in, thanks. > > That's something I wrote 9 years ago :) Still the top search result for how to work in staging, suggest an update. :)

  1   2   3   4   >