On Wed, Dec 5, 2018 at 7:20 AM Anson Huang wrote:
>
> Add accelerometer sensor mma8451 support on i2c1 bus.
>
> Signed-off-by: Anson Huang
Reviewed-by: Fabio Estevam
On Wed, Dec 5, 2018 at 7:20 AM Anson Huang wrote:
>
> Add accelerometer sensor mma8451 support on i2c1 bus.
>
> Signed-off-by: Anson Huang
Reviewed-by: Fabio Estevam
Hi Morimoto-san
Thanks for your comments
On 2018/12/05 17:58, Kuninori Morimoto wrote:
Hi Jiada
There are AVB Counter Clocks in ADG, each clock has 12bits integral
and 8 bits fractional dividers which operates with S0D1ϕ clock.
This patch registers 8 AVB Counter Clocks when clock-cells of
Hi Morimoto-san
will rename dt bindings doc in next version
Thanks.
Jiada
On 2018/12/05 18:04, Kuninori Morimoto wrote:
Hi Jiada
Add device tree bindings for Audio Clock Generator (ADG)
of R-Car Socs.
Signed-off-by: Jiada Wang
---
.../clock/renesas,rcar-adg-clocks.txt | 24
Hi Morimoto-san
Thanks for your comments
On 2018/12/05 17:58, Kuninori Morimoto wrote:
Hi Jiada
There are AVB Counter Clocks in ADG, each clock has 12bits integral
and 8 bits fractional dividers which operates with S0D1ϕ clock.
This patch registers 8 AVB Counter Clocks when clock-cells of
Hi Morimoto-san
will rename dt bindings doc in next version
Thanks.
Jiada
On 2018/12/05 18:04, Kuninori Morimoto wrote:
Hi Jiada
Add device tree bindings for Audio Clock Generator (ADG)
of R-Car Socs.
Signed-off-by: Jiada Wang
---
.../clock/renesas,rcar-adg-clocks.txt | 24
On Monday, December 3, 2018 12:30:24 AM CET Linus Torvalds wrote:
> Hmm.. I'd like to say it was a normal week, but I'd be lying. rc5 is
> the biggest rc so far (with the obvious exception of rc1), and it
> looks fairly unusual in the diffstat too, with almost a third being
> arch updates. Yes,
On Monday, December 3, 2018 12:30:24 AM CET Linus Torvalds wrote:
> Hmm.. I'd like to say it was a normal week, but I'd be lying. rc5 is
> the biggest rc so far (with the obvious exception of rc1), and it
> looks fairly unusual in the diffstat too, with almost a third being
> arch updates. Yes,
Em Wed, Dec 05, 2018 at 11:42:22AM +0900, Namhyung Kim escreveu:
> On Tue, Dec 04, 2018 at 12:34:20PM -0800, Mark Drayton wrote:
> > The default timeout of 500ms for parsing /proc//maps files is too
> > short for profiling many of our services. This can be overridden by
> > passing
On Mon, Dec 3, 2018 at 12:06 PM Uwe Kleine-König
wrote:
> On Mon, Dec 03, 2018 at 11:57:26AM +0100, Bartosz Golaszewski wrote:
> > It used to live in the gpio-mockup driver and I generalized it
> > precisely because there was another driver - iio evgen - which was
> > doing basically the same
Em Wed, Dec 05, 2018 at 11:42:22AM +0900, Namhyung Kim escreveu:
> On Tue, Dec 04, 2018 at 12:34:20PM -0800, Mark Drayton wrote:
> > The default timeout of 500ms for parsing /proc//maps files is too
> > short for profiling many of our services. This can be overridden by
> > passing
On Mon, Dec 3, 2018 at 12:06 PM Uwe Kleine-König
wrote:
> On Mon, Dec 03, 2018 at 11:57:26AM +0100, Bartosz Golaszewski wrote:
> > It used to live in the gpio-mockup driver and I generalized it
> > precisely because there was another driver - iio evgen - which was
> > doing basically the same
On Wed, Dec 5, 2018 at 7:20 AM Anson Huang wrote:
>
> Add magnetometer sensor mag3110 support on i2c3 bus.
>
> Signed-off-by: Anson Huang
Reviewed-by: Fabio Estevam
On Wed, Dec 5, 2018 at 7:20 AM Anson Huang wrote:
>
> Add magnetometer sensor mag3110 support on i2c3 bus.
>
> Signed-off-by: Anson Huang
Reviewed-by: Fabio Estevam
On Tue, Dec 4, 2018 at 11:14 PM Anson Huang wrote:
>
> Add egalax touch screen support on i2c2 bus, it is connected
> to LVDS0, while the existing one on i2c3 bus is connected to
> LVDS1.
>
> Signed-off-by: Anson Huang
Reviewed-by: Fabio Estevam
On Tue, Dec 4, 2018 at 11:14 PM Anson Huang wrote:
>
> Add egalax touch screen support on i2c2 bus, it is connected
> to LVDS0, while the existing one on i2c3 bus is connected to
> LVDS1.
>
> Signed-off-by: Anson Huang
Reviewed-by: Fabio Estevam
Hi Anson,
On Wed, Dec 5, 2018 at 7:20 AM Anson Huang wrote:
>
> Add isl29023 light sensor support on i2c3 bus, the light
> sensor's power is controlled by a fixed regulator, since
> the isl29023 driver and most of other sensors on same
> board like mag3110 and mma8451 do NOT support regulator
>
Hi Anson,
On Wed, Dec 5, 2018 at 7:20 AM Anson Huang wrote:
>
> Add isl29023 light sensor support on i2c3 bus, the light
> sensor's power is controlled by a fixed regulator, since
> the isl29023 driver and most of other sensors on same
> board like mag3110 and mma8451 do NOT support regulator
>
Sorry typo.
I meant modular.
On 05 December 2018 12:02, Steve Twiss wrote:
> Subject: RE: [PATCH v2 00/22] mfd: demodularization of non-modular drivers
>
> Hi Paul,
>
> On 03 December 2018 04:23, Paul Gortmaker wrote:
>
> > Subject: [PATCH v2 00/22] mfd: demodularization of non-modular
Sorry typo.
I meant modular.
On 05 December 2018 12:02, Steve Twiss wrote:
> Subject: RE: [PATCH v2 00/22] mfd: demodularization of non-modular drivers
>
> Hi Paul,
>
> On 03 December 2018 04:23, Paul Gortmaker wrote:
>
> > Subject: [PATCH v2 00/22] mfd: demodularization of non-modular
On Wed 05-12-18 09:15:44, Amir Goldstein wrote:
> On Wed, Dec 5, 2018 at 1:44 AM Kees Cook wrote:
> >
> > As a precaution, make sure we check event_len when copying to userspace.
> > Based on old feedback: https://lkml.kernel.org/r/542d9fe5.3010...@gmx.de
> >
>
> This precaution serves the new
On Wed 05-12-18 09:15:44, Amir Goldstein wrote:
> On Wed, Dec 5, 2018 at 1:44 AM Kees Cook wrote:
> >
> > As a precaution, make sure we check event_len when copying to userspace.
> > Based on old feedback: https://lkml.kernel.org/r/542d9fe5.3010...@gmx.de
> >
>
> This precaution serves the new
On Tue 04-12-18 15:44:46, Kees Cook wrote:
> As a precaution, make sure we check event_len when copying to userspace.
> Based on old feedback: https://lkml.kernel.org/r/542d9fe5.3010...@gmx.de
>
> Signed-off-by: Kees Cook
Thanks for the patch, I've added it to my tree.
On Tue 04-12-18 15:44:46, Kees Cook wrote:
> As a precaution, make sure we check event_len when copying to userspace.
> Based on old feedback: https://lkml.kernel.org/r/542d9fe5.3010...@gmx.de
>
> Signed-off-by: Kees Cook
Thanks for the patch, I've added it to my tree.
On 12/5/18 4:58 AM, Greg Kroah-Hartman wrote:
> On Tue, Dec 04, 2018 at 07:09:46PM -0200, Rafael David Tinoco wrote:
>> On 12/4/18 8:48 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.19.7 release.
>>> There are 139 patches in this series, all will be
On 12/5/18 4:58 AM, Greg Kroah-Hartman wrote:
> On Tue, Dec 04, 2018 at 07:09:46PM -0200, Rafael David Tinoco wrote:
>> On 12/4/18 8:48 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.19.7 release.
>>> There are 139 patches in this series, all will be
Hi Paul,
On 03 December 2018 04:23, Paul Gortmaker wrote:
> Subject: [PATCH v2 00/22] mfd: demodularization of non-modular drivers
>
> [v1 --> v2: add some more commits as requested by Lee (MFD maintainer),
> update the 00/NN text; re-do build and link testing on new linux-next. ]
>
> This
Hi Paul,
On 03 December 2018 04:23, Paul Gortmaker wrote:
> Subject: [PATCH v2 00/22] mfd: demodularization of non-modular drivers
>
> [v1 --> v2: add some more commits as requested by Lee (MFD maintainer),
> update the 00/NN text; re-do build and link testing on new linux-next. ]
>
> This
On Mon, Dec 3, 2018 at 2:08 AM Matthias Brugger wrote:
> On 15/11/2018 11:04, Linus Walleij wrote:
> > On Wed, Nov 7, 2018 at 6:49 PM Manivannan Sadhasivam
> > wrote:
> >
> >> Add devicetree bindings for Mediatek MT6797 SoC Pin Controller.
> >>
> >> Signed-off-by: Manivannan Sadhasivam
> >
> >
On Mon, Dec 3, 2018 at 2:08 AM Matthias Brugger wrote:
> On 15/11/2018 11:04, Linus Walleij wrote:
> > On Wed, Nov 7, 2018 at 6:49 PM Manivannan Sadhasivam
> > wrote:
> >
> >> Add devicetree bindings for Mediatek MT6797 SoC Pin Controller.
> >>
> >> Signed-off-by: Manivannan Sadhasivam
> >
> >
Hi Boris,
On 03/12/18 2:49 PM, Boris Brezillon wrote:
> Hi Mark,
>
> On Mon, 3 Dec 2018 08:39:00 +
> Yogesh Narayan Gaur wrote:
>
>>
>> Yogesh Gaur (7):
>> spi: add support for octal mode I/O data transfer
>> spi: spi-mem: add support for octal mode I/O data transfer
>
> Can you take
Hi Boris,
On 03/12/18 2:49 PM, Boris Brezillon wrote:
> Hi Mark,
>
> On Mon, 3 Dec 2018 08:39:00 +
> Yogesh Narayan Gaur wrote:
>
>>
>> Yogesh Gaur (7):
>> spi: add support for octal mode I/O data transfer
>> spi: spi-mem: add support for octal mode I/O data transfer
>
> Can you take
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-4.20-rc6
with top-most commit a72173ecfc6774cf2d55de9fb29421ce69e3428c
Revert "exec: make de_thread() freezable"
on top of commit 2595646791c319cadfdbf271563aac97d0843dc7
Linux
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-4.20-rc6
with top-most commit a72173ecfc6774cf2d55de9fb29421ce69e3428c
Revert "exec: make de_thread() freezable"
on top of commit 2595646791c319cadfdbf271563aac97d0843dc7
Linux
inode.i_flags might be altered without proper
synchronisation when the inode belongs to devtmpfs.
The following stacktrace shows how to get there:
13: entry_SYSENTER_32:460
12: do_fast_syscall_32:410
11: _static_cpu_has:146
10: do_syscall_32_irqs_on:322
09: SyS_pwrite64:636
08: SYSC_pwrite64:650
inode.i_flags might be altered without proper
synchronisation when the inode belongs to devtmpfs.
The following stacktrace shows how to get there:
13: entry_SYSENTER_32:460
12: do_fast_syscall_32:410
11: _static_cpu_has:146
10: do_syscall_32_irqs_on:322
09: SyS_pwrite64:636
08: SYSC_pwrite64:650
On Mon, Dec 3, 2018 at 5:24 AM Paul Gortmaker
wrote:
> [v1 --> v2: add some more commits as requested by Lee (MFD maintainer),
> update the 00/NN text; re-do build and link testing on new linux-next. ]
>
> This group of MFD drivers are all controlled by "bool" Kconfig settings,
> but contain
On Mon, Dec 3, 2018 at 5:24 AM Paul Gortmaker
wrote:
> [v1 --> v2: add some more commits as requested by Lee (MFD maintainer),
> update the 00/NN text; re-do build and link testing on new linux-next. ]
>
> This group of MFD drivers are all controlled by "bool" Kconfig settings,
> but contain
On (12/05/18 19:42), Tetsuo Handa wrote:
> >>
> >> PID_MAX_LIMIT is 4194304, which can take up to 10 bytes if [T%u] is used.
> >
> > 4194304 is the worst case. I would use the same approach as with the
> > timestamp seconds. It uses 5 characters as the minimum. But it might
> > eventully get
On Wed, Dec 05, 2018 at 11:38:20AM +, Mark Brown wrote:
On Wed, Dec 05, 2018 at 04:33:54AM -0500, Sasha Levin wrote:
From: Keiji Hayashibara
[ Upstream commit 3511ba7d4ca6f39e2d060bb94e42a41ad1fee7bf ]
This commit fixes incorrect property because it was different
from the actual.
The
On (12/05/18 19:42), Tetsuo Handa wrote:
> >>
> >> PID_MAX_LIMIT is 4194304, which can take up to 10 bytes if [T%u] is used.
> >
> > 4194304 is the worst case. I would use the same approach as with the
> > timestamp seconds. It uses 5 characters as the minimum. But it might
> > eventully get
On Wed, Dec 05, 2018 at 11:38:20AM +, Mark Brown wrote:
On Wed, Dec 05, 2018 at 04:33:54AM -0500, Sasha Levin wrote:
From: Keiji Hayashibara
[ Upstream commit 3511ba7d4ca6f39e2d060bb94e42a41ad1fee7bf ]
This commit fixes incorrect property because it was different
from the actual.
The
On Wed, Dec 05, 2018 at 04:34:23AM -0500, Sasha Levin wrote:
> From: Pierre-Louis Bossart
>
> [ Upstream commit 4c10473d6ddf12ec124c9ff71a5d23bb5388478b ]
>
> On certain platforms, Display HDMI HDA codec was not going to sleep state
> after the use when links are powered down after turning off
On Wed, Dec 5, 2018 at 12:36 PM Charles Keepax
wrote:
> On Sun, Dec 02, 2018 at 11:23:07PM -0500, Paul Gortmaker wrote:
> > The solution to #4 is similar - we delete the ".remove" function and
> > the binding into the platform_driver struct. However, since the same
> > ".remove" function could
On Wednesday, December 5, 2018 12:31:04 PM CET Abhishek Goel wrote:
> This script adds support for auto-completion for cpupower tool.
> Added support for auto-completion of all the eight commands for
> cpupower tool and their all subsequent sub-commands, wherever
> possible.
>From what I see all
On Wed, Dec 05, 2018 at 04:34:23AM -0500, Sasha Levin wrote:
> From: Pierre-Louis Bossart
>
> [ Upstream commit 4c10473d6ddf12ec124c9ff71a5d23bb5388478b ]
>
> On certain platforms, Display HDMI HDA codec was not going to sleep state
> after the use when links are powered down after turning off
On Wed, Dec 5, 2018 at 12:36 PM Charles Keepax
wrote:
> On Sun, Dec 02, 2018 at 11:23:07PM -0500, Paul Gortmaker wrote:
> > The solution to #4 is similar - we delete the ".remove" function and
> > the binding into the platform_driver struct. However, since the same
> > ".remove" function could
On Wednesday, December 5, 2018 12:31:04 PM CET Abhishek Goel wrote:
> This script adds support for auto-completion for cpupower tool.
> Added support for auto-completion of all the eight commands for
> cpupower tool and their all subsequent sub-commands, wherever
> possible.
>From what I see all
On 12/5/18 12:12 PM, Krzysztof Kozlowski wrote:
> On Wed, 5 Dec 2018 at 12:06, Lukasz Luba wrote:
>>
>> Mark the state for devfreq device while entring suspend/resume process.
>>
>> Suggested-by: Tobias Jakobi
>> Suggested-by: Chanwoo Choi
>> Reviewed-by: Chanwoo Choi
>> Signed-off-by:
On 12/5/18 12:12 PM, Krzysztof Kozlowski wrote:
> On Wed, 5 Dec 2018 at 12:06, Lukasz Luba wrote:
>>
>> Mark the state for devfreq device while entring suspend/resume process.
>>
>> Suggested-by: Tobias Jakobi
>> Suggested-by: Chanwoo Choi
>> Reviewed-by: Chanwoo Choi
>> Signed-off-by:
No.
Don't try ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC model for ALC286 platform.
從: Jian-Hong Pan [jian-h...@endlessm.com]
寄件日期: 2018年12月5日 下午 05:33
至: Kailang
副本: Jaroslav Kysela; ti...@suse.com; Hui Wang; alsa-de...@alsa-project.org;
Linux Kernel; Linux
On Wed 05-12-18 10:43:43, Mel Gorman wrote:
> On Wed, Dec 05, 2018 at 10:08:56AM +0100, Michal Hocko wrote:
> > On Tue 04-12-18 16:47:23, David Rientjes wrote:
> > > On Tue, 4 Dec 2018, Mel Gorman wrote:
> > >
> > > > What should also be kept in mind is that we should avoid conflating
> > > >
On Wed 05-12-18 10:43:43, Mel Gorman wrote:
> On Wed, Dec 05, 2018 at 10:08:56AM +0100, Michal Hocko wrote:
> > On Tue 04-12-18 16:47:23, David Rientjes wrote:
> > > On Tue, 4 Dec 2018, Mel Gorman wrote:
> > >
> > > > What should also be kept in mind is that we should avoid conflating
> > > >
No.
Don't try ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC model for ALC286 platform.
從: Jian-Hong Pan [jian-h...@endlessm.com]
寄件日期: 2018年12月5日 下午 05:33
至: Kailang
副本: Jaroslav Kysela; ti...@suse.com; Hui Wang; alsa-de...@alsa-project.org;
Linux Kernel; Linux
Hi
On 2018/12/05 3:15, Stephen Boyd wrote:
Quoting Sugaya, Taichi (2018-12-04 00:26:16)
On 2018/11/30 17:31, Stephen Boyd wrote:
Quoting Sugaya Taichi (2018-11-18 17:01:12)
+void __init m10v_clk_mux_setup(struct device_node *node)
+{
+ const char *clk_name = node->name;
+ struct
Hi
On 2018/12/05 3:15, Stephen Boyd wrote:
Quoting Sugaya, Taichi (2018-12-04 00:26:16)
On 2018/11/30 17:31, Stephen Boyd wrote:
Quoting Sugaya Taichi (2018-11-18 17:01:12)
+void __init m10v_clk_mux_setup(struct device_node *node)
+{
+ const char *clk_name = node->name;
+ struct
On Sun, Dec 02, 2018 at 11:23:29PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/mfd/Kconfig:config MFD_WM8400
> drivers/mfd/Kconfig:bool "Wolfson Microelectronics WM8400"
>
> ...meaning that it currently is not being built as a
On Sun, Dec 02, 2018 at 11:23:29PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/mfd/Kconfig:config MFD_WM8400
> drivers/mfd/Kconfig:bool "Wolfson Microelectronics WM8400"
>
> ...meaning that it currently is not being built as a
On Sun, Dec 02, 2018 at 11:23:28PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/mfd/Kconfig:config MFD_WM8350
> drivers/mfd/Kconfig:bool
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove
On Sun, Dec 02, 2018 at 11:23:28PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/mfd/Kconfig:config MFD_WM8350
> drivers/mfd/Kconfig:bool
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove
On Thu, 29 Nov 2018, Petr Mladek wrote:
> From: Joe Lawrence
>
> Add a few livepatch modules and simple target modules that the included
> regression suite can run tests against:
>
> - basic livepatching (multiple patches, atomic replace)
> - pre/post (un)patch callbacks
> - shadow
On Sun, Dec 02, 2018 at 11:23:27PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/mfd/Kconfig:config MFD_WM8350_I2C
> drivers/mfd/Kconfig:bool "Wolfson Microelectronics WM8350 with I2C"
>
> ...meaning that it currently is not being
On Thu, 29 Nov 2018, Petr Mladek wrote:
> From: Joe Lawrence
>
> Add a few livepatch modules and simple target modules that the included
> regression suite can run tests against:
>
> - basic livepatching (multiple patches, atomic replace)
> - pre/post (un)patch callbacks
> - shadow
On Sun, Dec 02, 2018 at 11:23:27PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/mfd/Kconfig:config MFD_WM8350_I2C
> drivers/mfd/Kconfig:bool "Wolfson Microelectronics WM8350 with I2C"
>
> ...meaning that it currently is not being
On Wed, Dec 05, 2018 at 04:33:54AM -0500, Sasha Levin wrote:
> From: Keiji Hayashibara
>
> [ Upstream commit 3511ba7d4ca6f39e2d060bb94e42a41ad1fee7bf ]
>
> This commit fixes incorrect property because it was different
> from the actual.
> The parameters of '#address-cells' and '#size-cells'
On Sun, Dec 02, 2018 at 11:23:25PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/mfd/Kconfig:config MFD_WM831X_I2C
> drivers/mfd/Kconfig:bool "Wolfson Microelectronics WM831x/2x PMICs with
> I2C"
>
> ...meaning that it currently is
On Sun, Dec 02, 2018 at 11:23:25PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/mfd/Kconfig:config MFD_WM831X_I2C
> drivers/mfd/Kconfig:bool "Wolfson Microelectronics WM831x/2x PMICs with
> I2C"
>
> ...meaning that it currently is
On Wed, Dec 05, 2018 at 04:33:54AM -0500, Sasha Levin wrote:
> From: Keiji Hayashibara
>
> [ Upstream commit 3511ba7d4ca6f39e2d060bb94e42a41ad1fee7bf ]
>
> This commit fixes incorrect property because it was different
> from the actual.
> The parameters of '#address-cells' and '#size-cells'
Hi Stephen,
I maintain the Thunderbolt tree that gets merged to mainline via Greg's
char-misc tree. I would like to get the tree included in linux-next to
get wider coverage before it hits Greg's tree.
Can you please include branches 'fixes' and 'next' from:
On Wed 05-12-18 19:01:03, Nicolas Boichat wrote:
[...]
> > Secondly, why do we need a new sysfs file? Who is going to consume it?
>
> We have cache_dma, so it seems consistent to add cache_dma32.
I wouldn't copy a pattern unless there is an explicit usecase for it.
We do expose way too much to
Hi Stephen,
I maintain the Thunderbolt tree that gets merged to mainline via Greg's
char-misc tree. I would like to get the tree included in linux-next to
get wider coverage before it hits Greg's tree.
Can you please include branches 'fixes' and 'next' from:
On Wed 05-12-18 19:01:03, Nicolas Boichat wrote:
[...]
> > Secondly, why do we need a new sysfs file? Who is going to consume it?
>
> We have cache_dma, so it seems consistent to add cache_dma32.
I wouldn't copy a pattern unless there is an explicit usecase for it.
We do expose way too much to
On Sun, Dec 02, 2018 at 11:23:07PM -0500, Paul Gortmaker wrote:
> The solution to #4 is similar - we delete the ".remove" function and
> the binding into the platform_driver struct. However, since the same
> ".remove" function could also be triggered by an "unbind" (such as for
> pass-through of
On Sun, Dec 02, 2018 at 11:23:07PM -0500, Paul Gortmaker wrote:
> The solution to #4 is similar - we delete the ".remove" function and
> the binding into the platform_driver struct. However, since the same
> ".remove" function could also be triggered by an "unbind" (such as for
> pass-through of
On Sun, Dec 02, 2018 at 11:23:26PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/mfd/Kconfig:config MFD_WM831X
> drivers/mfd/Kconfig:bool
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove
On Sun, Dec 02, 2018 at 11:23:26PM -0500, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/mfd/Kconfig:config MFD_WM831X
> drivers/mfd/Kconfig:bool
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove
On Wed, 05 Dec 2018, Lee Jones wrote:
> On Wed, 05 Dec 2018, Cheng-yi Chiang wrote:
>
> > Hi Lee,
> >
> > I tried to apply this patch based on
> > for-mfd-next branch of mfd tree (
> > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git )
> > Then, I tried to compile all modules by
> >
>
On Wed, 05 Dec 2018, Lee Jones wrote:
> On Wed, 05 Dec 2018, Cheng-yi Chiang wrote:
>
> > Hi Lee,
> >
> > I tried to apply this patch based on
> > for-mfd-next branch of mfd tree (
> > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git )
> > Then, I tried to compile all modules by
> >
>
This script adds support for auto-completion for cpupower tool.
Added support for auto-completion of all the eight commands for
cpupower tool and their all subsequent sub-commands, wherever
possible.
A sample output after applying this script -
root@ubuntu:~# cpupower f
root@ubuntu:~# cpupower
This script adds support for auto-completion for cpupower tool.
Added support for auto-completion of all the eight commands for
cpupower tool and their all subsequent sub-commands, wherever
possible.
A sample output after applying this script -
root@ubuntu:~# cpupower f
root@ubuntu:~# cpupower
On Wed, 05 Dec 2018, Cheng-yi Chiang wrote:
> Hi Lee,
>
> I tried to apply this patch based on
> for-mfd-next branch of mfd tree (
> git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git )
> Then, I tried to compile all modules by
>
> ARCH=x86_64 make allyesconfig
> ARCH=x86_64 make -j64
On Wed, 05 Dec 2018, Cheng-yi Chiang wrote:
> Hi Lee,
>
> I tried to apply this patch based on
> for-mfd-next branch of mfd tree (
> git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git )
> Then, I tried to compile all modules by
>
> ARCH=x86_64 make allyesconfig
> ARCH=x86_64 make -j64
- Use conventional $(MAKE) $(asm-generic)= style
for directory descending
- Remove unneeded FORCE since "all" is a phony target
- Remove unneeded "_dummy :=" assignment
- Skip $(shell mkdir ...) when headers exist in the directory
- Misc cleanups
Signed-off-by: Masahiro Yamada
---
- Use conventional $(MAKE) $(asm-generic)= style
for directory descending
- Remove unneeded FORCE since "all" is a phony target
- Remove unneeded "_dummy :=" assignment
- Skip $(shell mkdir ...) when headers exist in the directory
- Misc cleanups
Signed-off-by: Masahiro Yamada
---
On Wed, Dec 05, 2018 at 10:21:04AM +, Adam Thomson wrote:
> If the previous I2C access failed, how can we be sure that the write back to
> HW
> of 0xFF even succeeds? More importantly these error returns won't necessarily
> stop subsequent calls to controls within the Codec I believe, so you
On Wed, Dec 05, 2018 at 10:21:04AM +, Adam Thomson wrote:
> If the previous I2C access failed, how can we be sure that the write back to
> HW
> of 0xFF even succeeds? More importantly these error returns won't necessarily
> stop subsequent calls to controls within the Codec I believe, so you
We can use extended format when writing /sys/.../uevent files to
generate synthetic uevents, introduced with commit f36776fafbaa
("kobject: support passing in variables for synthetic uevents").
Before using this extended format, we need to know if it's supported
and kernel version check may not
We can use extended format when writing /sys/.../uevent files to
generate synthetic uevents, introduced with commit f36776fafbaa
("kobject: support passing in variables for synthetic uevents").
Before using this extended format, we need to know if it's supported
and kernel version check may not
Propagate error code back to userspace if writing the /sys/.../uevent
file fails. Before, the write operation always returned with success,
even if we failed to recognize the input string or if we failed to
generate the uevent itself.
With the error codes properly propagated back to userspace, we
On 12/5/18 12:19 AM, Jerome Glisse wrote:
Above example is for migrate. Here is an example for how the
topology is use today:
Application knows that the platform is running on have 16
GPU split into 2 group of 8 GPUs each. GPU in each group can
access each other memory with
Two small patches to aid handling of synthetic uevents back in userspace:
- Return error code back to userspace on /sys/.../uevent file write
failure so userspace knows and it can act accordingly.
- Add new 'kernel/uevent_features' sysfs file to make it possible for
userspace to
Propagate error code back to userspace if writing the /sys/.../uevent
file fails. Before, the write operation always returned with success,
even if we failed to recognize the input string or if we failed to
generate the uevent itself.
With the error codes properly propagated back to userspace, we
On 12/5/18 12:19 AM, Jerome Glisse wrote:
Above example is for migrate. Here is an example for how the
topology is use today:
Application knows that the platform is running on have 16
GPU split into 2 group of 8 GPUs each. GPU in each group can
access each other memory with
Two small patches to aid handling of synthetic uevents back in userspace:
- Return error code back to userspace on /sys/.../uevent file write
failure so userspace knows and it can act accordingly.
- Add new 'kernel/uevent_features' sysfs file to make it possible for
userspace to
On 2018-12-05 00:59, Andrea Parri wrote:
Hi Roman,
On Tue, Dec 04, 2018 at 12:50:58PM +0100, Roman Penyaev wrote:
On 2018-12-03 18:34, Linus Torvalds wrote:
> This also ends up making the memory ordering of "xchg()" very very
> important. Yes, we've documented it as being an ordering op,
On 2018-12-05 00:59, Andrea Parri wrote:
Hi Roman,
On Tue, Dec 04, 2018 at 12:50:58PM +0100, Roman Penyaev wrote:
On 2018-12-03 18:34, Linus Torvalds wrote:
> This also ends up making the memory ordering of "xchg()" very very
> important. Yes, we've documented it as being an ordering op,
On 2018-12-04 20:02, Paul E. McKenney wrote:
On Tue, Dec 04, 2018 at 12:23:08PM -0500, Jason Baron wrote:
On 12/3/18 6:02 AM, Roman Penyaev wrote:
> Hi all,
>
> The goal of this patch is to reduce contention of ep_poll_callback() which
> can be called concurrently from different CPUs in case
On 2018-12-04 20:02, Paul E. McKenney wrote:
On Tue, Dec 04, 2018 at 12:23:08PM -0500, Jason Baron wrote:
On 12/3/18 6:02 AM, Roman Penyaev wrote:
> Hi all,
>
> The goal of this patch is to reduce contention of ep_poll_callback() which
> can be called concurrently from different CPUs in case
On the vf610-zii-scu4-aib board there is a hi8435 (32-channel
discrete-to-digital SPI sensor device) in the DSPI0 bus.
Add support for it.
Signed-off-by: Fabio Estevam
Reviewed-by: Chris Healy
---
Changes since v1:
- Put status as the last propert
- Use a generic node name
On the vf610-zii-scu4-aib board there is a hi8435 (32-channel
discrete-to-digital SPI sensor device) in the DSPI0 bus.
Add support for it.
Signed-off-by: Fabio Estevam
Reviewed-by: Chris Healy
---
Changes since v1:
- Put status as the last propert
- Use a generic node name
1501 - 1600 of 2376 matches
Mail list logo
