On Thu, Aug 16, 2018 at 12:21:42PM -0700, Jolly Shah wrote:
> From: Rajan Vaja
>
> Add documentation to describe ZynqMP power domain bindings.
>
> Signed-off-by: Rajan Vaja
> Signed-off-by: Jolly Shah
> ---
> .../firmware/xilinx/xlnx,zynqmp-firmware.txt | 47
> ++
On Thu, Aug 16, 2018 at 12:21:42PM -0700, Jolly Shah wrote:
> From: Rajan Vaja
>
> Add documentation to describe ZynqMP power domain bindings.
>
> Signed-off-by: Rajan Vaja
> Signed-off-by: Jolly Shah
> ---
> .../firmware/xilinx/xlnx,zynqmp-firmware.txt | 47
> ++
On Thu, Aug 16, 2018 at 12:08:01PM -0700, Jolly Shah wrote:
> From: Rajan Vaja
>
> Add documentation to describe Xilinx ZynqMP power management
> bindings.
>
> Signed-off-by: Rajan Vaja
> Signed-off-by: Jolly Shah
> ---
> .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt| 16
>
On Thu, Aug 16, 2018 at 12:08:01PM -0700, Jolly Shah wrote:
> From: Rajan Vaja
>
> Add documentation to describe Xilinx ZynqMP power management
> bindings.
>
> Signed-off-by: Rajan Vaja
> Signed-off-by: Jolly Shah
> ---
> .../bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt| 16
>
On Thu, 16 Aug 2018 20:54:50 +0800, Baolin Wang wrote:
> From: Lanqing Liu
>
> This patch adds the binding documentation for Spreadtrum SPI
> controller device.
>
> Signed-off-by: Lanqing Liu
> Signed-off-by: Baolin Wang
> ---
> Changes from v1:
> - Remove the sprd,spi-interval property.
>
On Thu, 16 Aug 2018 20:54:50 +0800, Baolin Wang wrote:
> From: Lanqing Liu
>
> This patch adds the binding documentation for Spreadtrum SPI
> controller device.
>
> Signed-off-by: Lanqing Liu
> Signed-off-by: Baolin Wang
> ---
> Changes from v1:
> - Remove the sprd,spi-interval property.
>
On Mon, Aug 20, 2018 at 02:36:20PM +0900, Roy Im wrote:
>
> from: Roy Im
Looks like this needs to be removed. You should only have 'From' line
show up when the sender and author emails are different.
>
> Add device tree binding information for DA7280 haptic driver.
> Example bindings for
On Mon, Aug 20, 2018 at 02:36:20PM +0900, Roy Im wrote:
>
> from: Roy Im
Looks like this needs to be removed. You should only have 'From' line
show up when the sender and author emails are different.
>
> Add device tree binding information for DA7280 haptic driver.
> Example bindings for
On 20/08/2018 13:13:41-0500, Rob Herring wrote:
> On Thu, Aug 16, 2018 at 10:45:18AM +0200, Alexandre Belloni wrote:
> > Document bindings for the Microsemi Ocelot integration of the Designware
> > I2C controller.
> >
> > Cc: Rob Herring
> > Signed-off-by: Alexandre Belloni
> > ---
> >
On 20/08/2018 13:13:41-0500, Rob Herring wrote:
> On Thu, Aug 16, 2018 at 10:45:18AM +0200, Alexandre Belloni wrote:
> > Document bindings for the Microsemi Ocelot integration of the Designware
> > I2C controller.
> >
> > Cc: Rob Herring
> > Signed-off-by: Alexandre Belloni
> > ---
> >
On Mon, Aug 20, 2018 at 12:22 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote:
> > If kobject state is not initialized, then its not even certain that
> > kobject'name is initialized. Hence when accessing the kobject's name
> > tread carefully.
>
On Mon, Aug 20, 2018 at 12:22 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote:
> > If kobject state is not initialized, then its not even certain that
> > kobject'name is initialized. Hence when accessing the kobject's name
> > tread carefully.
>
Remove references to deprecated features like NMI sourcing
and obsoleted module parameters.
Add details concerning new module parameter pretimeout and tips
to programming it.
Signed-off-by: Jerry Hoemann
---
Documentation/watchdog/hpwdt.txt | 93 ++--
1 file
Remove references to deprecated features like NMI sourcing
and obsoleted module parameters.
Add details concerning new module parameter pretimeout and tips
to programming it.
Signed-off-by: Jerry Hoemann
---
Documentation/watchdog/hpwdt.txt | 93 ++--
1 file
On Sat, Aug 18, 2018 at 12:51:14AM -0500, Eric W. Biederman wrote:
> I was dismayed when I saw the syzbot report triggered someone to remove
> themselves from MAINTAINERS.
You're talking about my patch? I think you misread it, I'm not removing
myself from MAINTAINERS.
--b.
On Sat, Aug 18, 2018 at 12:51:14AM -0500, Eric W. Biederman wrote:
> I was dismayed when I saw the syzbot report triggered someone to remove
> themselves from MAINTAINERS.
You're talking about my patch? I think you misread it, I'm not removing
myself from MAINTAINERS.
--b.
On Mon, Aug 20, 2018 at 9:31 AM Tony Luck wrote:
> I'd suggested an #if !CONFIG_IA64 in the functon, but Arnd
> suggested keeping the fix inside the arch/ia64 tree.
>
> Fixes: 0bbf47eab469 ("ia64: use asm-generic/io.h")
Applied.
Linus
On Mon, Aug 20, 2018 at 9:31 AM Tony Luck wrote:
> I'd suggested an #if !CONFIG_IA64 in the functon, but Arnd
> suggested keeping the fix inside the arch/ia64 tree.
>
> Fixes: 0bbf47eab469 ("ia64: use asm-generic/io.h")
Applied.
Linus
On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote:
> If kobject state is not initialized, then its not even certain that
> kobject'name is initialized. Hence when accessing the kobject's name
> tread carefully.
>
> A stupid module test like
>
On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote:
> If kobject state is not initialized, then its not even certain that
> kobject'name is initialized. Hence when accessing the kobject's name
> tread carefully.
>
> A stupid module test like
>
Hi,
Le lun. 20 août 2018 à 21:12, Alexandre Belloni
a écrit :
On 20/08/2018 20:07:16+0200, Paul Cercueil wrote:
Depending on MACH_INGENIC prevent us from creating a generic kernel
that
works on more than one MIPS board. Instead, we just depend on MIPS
being
set.
Maybe you could
Hi,
Le lun. 20 août 2018 à 21:12, Alexandre Belloni
a écrit :
On 20/08/2018 20:07:16+0200, Paul Cercueil wrote:
Depending on MACH_INGENIC prevent us from creating a generic kernel
that
works on more than one MIPS board. Instead, we just depend on MIPS
being
set.
Maybe you could
On Mon 20-08-18 10:07:44, Matthew Wilcox wrote:
> On Mon, Aug 20, 2018 at 06:24:06PM +0200, Michal Hocko wrote:
> > On Mon 20-08-18 07:49:23, Matthew Wilcox wrote:
> > > On Mon, Aug 20, 2018 at 04:41:16PM +0200, Michal Hocko wrote:
> > > > On Sat 18-08-18 20:49:01, Li RongQing wrote:
> > > > > The
On Mon 20-08-18 10:07:44, Matthew Wilcox wrote:
> On Mon, Aug 20, 2018 at 06:24:06PM +0200, Michal Hocko wrote:
> > On Mon 20-08-18 07:49:23, Matthew Wilcox wrote:
> > > On Mon, Aug 20, 2018 at 04:41:16PM +0200, Michal Hocko wrote:
> > > > On Sat 18-08-18 20:49:01, Li RongQing wrote:
> > > > > The
On Mon 20-08-18 11:03:53, Andi Kleen wrote:
> On Mon, Aug 20, 2018 at 06:29:38PM +0200, Michal Hocko wrote:
> > On Fri 17-08-18 15:27:33, Guenter Roeck wrote:
> > > Hi,
> > >
> > > the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> > > with CONFIG_TRANSPARENT_HUGEPAGE=y,
On Mon 20-08-18 11:03:53, Andi Kleen wrote:
> On Mon, Aug 20, 2018 at 06:29:38PM +0200, Michal Hocko wrote:
> > On Fri 17-08-18 15:27:33, Guenter Roeck wrote:
> > > Hi,
> > >
> > > the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> > > with CONFIG_TRANSPARENT_HUGEPAGE=y,
On 20/08/2018 20:07:16+0200, Paul Cercueil wrote:
> Depending on MACH_INGENIC prevent us from creating a generic kernel that
> works on more than one MIPS board. Instead, we just depend on MIPS being
> set.
Maybe you could consider dropping the whole dependency as we already
know it will build on
On 20/08/2018 20:07:16+0200, Paul Cercueil wrote:
> Depending on MACH_INGENIC prevent us from creating a generic kernel that
> works on more than one MIPS board. Instead, we just depend on MIPS being
> set.
Maybe you could consider dropping the whole dependency as we already
know it will build on
On Sun, Aug 19, 2018 at 04:26:50PM -0700, David Rientjes wrote:
> Roman, have you had time to go through this?
Hm, I thought we've finished this part of discussion, no?
Anyway, let me repeat my position: I don't like the interface
you've proposed in that follow-up patchset, and I explained why.
On Sun, Aug 19, 2018 at 04:26:50PM -0700, David Rientjes wrote:
> Roman, have you had time to go through this?
Hm, I thought we've finished this part of discussion, no?
Anyway, let me repeat my position: I don't like the interface
you've proposed in that follow-up patchset, and I explained why.
On 07/03/18 18:59, Masahiro Yamada wrote:
> It is tedious to specify extra compiler options for every file.
> HOST_EXTRACFLAGS is useful to add options to all files in a
> directory.
>
> -I$(src)/libfdt is needed for all the files in this directory
> to include libfdt_env.h etc. from
On 07/03/18 18:59, Masahiro Yamada wrote:
> It is tedious to specify extra compiler options for every file.
> HOST_EXTRACFLAGS is useful to add options to all files in a
> directory.
>
> -I$(src)/libfdt is needed for all the files in this directory
> to include libfdt_env.h etc. from
hello Colin,
On Mon, Jul 30, 2018 at 01:27:16PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently the drvdata allocation failure is being incorrectly checked by
> checking priv and not drvdata. Fix this and also free priv to fix a
> memory leak.
>
> Detected by Coverity Scan,
hello Colin,
On Mon, Jul 30, 2018 at 01:27:16PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently the drvdata allocation failure is being incorrectly checked by
> checking priv and not drvdata. Fix this and also free priv to fix a
> memory leak.
>
> Detected by Coverity Scan,
On Mon, Aug 20, 2018 at 9:07 AM Maxime Ripard wrote:
>
> On Mon, Aug 20, 2018 at 07:41:22AM -0600, Rob Herring wrote:
> > On Mon, Aug 20, 2018 at 5:17 AM Maxime Ripard
> > wrote:
> > >
> > > On Sat, Aug 04, 2018 at 09:03:49AM +0200, Emmanuel Vadot wrote:
> > > > This patch adds documentation
On Mon, Aug 20, 2018 at 9:07 AM Maxime Ripard wrote:
>
> On Mon, Aug 20, 2018 at 07:41:22AM -0600, Rob Herring wrote:
> > On Mon, Aug 20, 2018 at 5:17 AM Maxime Ripard
> > wrote:
> > >
> > > On Sat, Aug 04, 2018 at 09:03:49AM +0200, Emmanuel Vadot wrote:
> > > > This patch adds documentation
Good morning.
I have a custom PCI device that needs to fill memory buffers of up to 16MB
in size. For various reasons I would like to avoid implementing
scatter-gather support in the device and would much rather prefer a
contiguous buffer view instead. The buffers are allocated using
Good morning.
I have a custom PCI device that needs to fill memory buffers of up to 16MB
in size. For various reasons I would like to avoid implementing
scatter-gather support in the device and would much rather prefer a
contiguous buffer view instead. The buffers are allocated using
On Mon, Aug 20, 2018 at 10:46 AM Nick Desaulniers
wrote:
>
> I think we should take Joe's patch.
I'll happily take Joe's patch and get the whole "ancient gcc versions"
issue behind us.
We'll come back to it in a few years when 4.6 is ancient too, but for
now we have no pressing need not to
On Mon, Aug 20, 2018 at 10:46 AM Nick Desaulniers
wrote:
>
> I think we should take Joe's patch.
I'll happily take Joe's patch and get the whole "ancient gcc versions"
issue behind us.
We'll come back to it in a few years when 4.6 is ancient too, but for
now we have no pressing need not to
Hi Masahiro,
On Mon, Aug 20, 2018 at 02:04:24PM +0900, Masahiro Yamada wrote:
> 2018-08-19 3:10 GMT+09:00 Paul Burton :
> > We have a need to override the definition of
> > barrier_before_unreachable() for MIPS, which means we either need to add
> > architecture-specific code into
Hi Masahiro,
On Mon, Aug 20, 2018 at 02:04:24PM +0900, Masahiro Yamada wrote:
> 2018-08-19 3:10 GMT+09:00 Paul Burton :
> > We have a need to override the definition of
> > barrier_before_unreachable() for MIPS, which means we either need to add
> > architecture-specific code into
On Mon, 20 Aug 2018 12:01:14 +0200
Peter Rosin wrote:
> Drop the boilerplate license text.
>
> Signed-off-by: Peter Rosin
Applied.
Thanks,
Jonathan
> ---
> drivers/iio/multiplexer/iio-mux.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git
On Mon, 20 Aug 2018 12:01:14 +0200
Peter Rosin wrote:
> Drop the boilerplate license text.
>
> Signed-off-by: Peter Rosin
Applied.
Thanks,
Jonathan
> ---
> drivers/iio/multiplexer/iio-mux.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git
On Mon, 20 Aug 2018 12:01:13 +0200
Peter Rosin wrote:
> Drop the boilerplate license text.
>
> Signed-off-by: Peter Rosin
Applied. Thanks
> ---
> drivers/iio/dac/dpot-dac.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/iio/dac/dpot-dac.c
On Mon, 20 Aug 2018 12:01:13 +0200
Peter Rosin wrote:
> Drop the boilerplate license text.
>
> Signed-off-by: Peter Rosin
Applied. Thanks
> ---
> drivers/iio/dac/dpot-dac.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/iio/dac/dpot-dac.c
On Mon, 20 Aug 2018 12:01:12 +0200
Peter Rosin wrote:
> Drop the boilerplate license text.
>
> Signed-off-by: Peter Rosin
Applied, thanks.
> ---
> drivers/iio/adc/envelope-detector.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git
On Mon, 20 Aug 2018 12:01:12 +0200
Peter Rosin wrote:
> Drop the boilerplate license text.
>
> Signed-off-by: Peter Rosin
Applied, thanks.
> ---
> drivers/iio/adc/envelope-detector.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git
On Mon, 20 Aug 2018 12:01:11 +0200
Peter Rosin wrote:
> Drop the boilerplate license text and use the correct MODULE_LICENSE.
>
> Signed-off-by: Peter Rosin
Applied.
thanks,
Jonathan
> ---
> drivers/iio/potentiometer/mcp4531.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
On Mon, 20 Aug 2018 12:01:11 +0200
Peter Rosin wrote:
> Drop the boilerplate license text and use the correct MODULE_LICENSE.
>
> Signed-off-by: Peter Rosin
Applied.
thanks,
Jonathan
> ---
> drivers/iio/potentiometer/mcp4531.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
On Mon, 20 Aug 2018 12:01:10 +0200
Peter Rosin wrote:
> The file is GPL v2 only.
>
> Signed-off-by: Peter Rosin
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
thanks,
Jonathan
> ---
> drivers/iio/potentiometer/mcp4018.c | 2 +-
> 1
On Mon, 20 Aug 2018 12:01:10 +0200
Peter Rosin wrote:
> The file is GPL v2 only.
>
> Signed-off-by: Peter Rosin
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
thanks,
Jonathan
> ---
> drivers/iio/potentiometer/mcp4018.c | 2 +-
> 1
Quoting Douglas Anderson (2018-08-10 14:51:49)
> @@ -20,6 +21,450 @@
> chosen {
> stdout-path = "serial0:115200n8";
> };
> +
> + vph_pwr: vph-pwr-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vph_pwr";
> +
Quoting Douglas Anderson (2018-08-10 14:51:49)
> @@ -20,6 +21,450 @@
> chosen {
> stdout-path = "serial0:115200n8";
> };
> +
> + vph_pwr: vph-pwr-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vph_pwr";
> +
Quoting Douglas Anderson (2018-08-10 14:51:48)
> From: Manu Gautam
>
> This adds nodes for USB and related PHYs.
>
> Signed-off-by: Manu Gautam
> [dianders: reworked quite a bit]
> Signed-off-by: Douglas Anderson
> ---
One question below, otherwise
Reviewed-by: Stephen Boyd
>
> Changes
Quoting Douglas Anderson (2018-08-10 14:51:48)
> From: Manu Gautam
>
> This adds nodes for USB and related PHYs.
>
> Signed-off-by: Manu Gautam
> [dianders: reworked quite a bit]
> Signed-off-by: Douglas Anderson
> ---
One question below, otherwise
Reviewed-by: Stephen Boyd
>
> Changes
Fixes: 99f396587875 ("x86/platform/uv/BAU: Gracefully disable BAU during panic")
Signed-off-by: kbuild test robot
---
tlb_uv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index 4c1e119..bce4d14 100644
---
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent
head: 99f3965878759d36baac944df004b4dafcc272b4
commit: 99f3965878759d36baac944df004b4dafcc272b4 [6/6] x86/platform/uv/BAU:
Gracefully disable BAU during panic
reproduce:
# apt-get install sparse
git
Fixes: 99f396587875 ("x86/platform/uv/BAU: Gracefully disable BAU during panic")
Signed-off-by: kbuild test robot
---
tlb_uv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index 4c1e119..bce4d14 100644
---
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent
head: 99f3965878759d36baac944df004b4dafcc272b4
commit: 99f3965878759d36baac944df004b4dafcc272b4 [6/6] x86/platform/uv/BAU:
Gracefully disable BAU during panic
reproduce:
# apt-get install sparse
git
On Thu, Aug 16, 2018 at 10:45:18AM +0200, Alexandre Belloni wrote:
> Document bindings for the Microsemi Ocelot integration of the Designware
> I2C controller.
>
> Cc: Rob Herring
> Signed-off-by: Alexandre Belloni
> ---
> Documentation/devicetree/bindings/i2c/i2c-designware.txt | 7 ++-
>
On Thu, Aug 16, 2018 at 10:45:18AM +0200, Alexandre Belloni wrote:
> Document bindings for the Microsemi Ocelot integration of the Designware
> I2C controller.
>
> Cc: Rob Herring
> Signed-off-by: Alexandre Belloni
> ---
> Documentation/devicetree/bindings/i2c/i2c-designware.txt | 7 ++-
>
Don't request MODEM IRQ GPIO by its global number in
ams_delta_modem_init(). Instead, obtain its GPIO descriptor
and assign related IRQ to the MODEM. Do that from
omap_gpio_deps_init(), where the chip is already looked up. Then, in
ams_delta_modem_init(), just check for the IRQ number having
Don't request MODEM IRQ GPIO by its global number in
ams_delta_modem_init(). Instead, obtain its GPIO descriptor
and assign related IRQ to the MODEM. Do that from
omap_gpio_deps_init(), where the chip is already looked up. Then, in
ams_delta_modem_init(), just check for the IRQ number having
Convert modem related GPIO setup from integer space to GPIO descriptors.
Also, restore original initialization order of the MODEM device and its
related GPIO pins.
Cleanup of MODEM relaated regulator setup is postponed while waiting for
upcoming conversion of fixed regulator API to GPIO
Amstrad Delta MODEM device used to be initialized at arch_initcall
before it was once moved to late_initcall by commit f7519d8c8290 ("ARM:
OMAP1: ams-delta: register latch dependent devices later"). The purpose
of that change was to postpone initialization of devices which depended
on latch2 pins
Latch2 pins control a number of on-board devices, namely LCD, NAND,
MODEM and CODEC. Those pins used to be initialized with safe values
from init_machine before that operation was:
1) moved to late_initcall in preparation for conversion of latch2 to
GPIO device - see commit f7519d8c8290 ("ARM:
Amstrad Delta MODEM device used to be initialized at arch_initcall
before it was once moved to late_initcall by commit f7519d8c8290 ("ARM:
OMAP1: ams-delta: register latch dependent devices later"). The purpose
of that change was to postpone initialization of devices which depended
on latch2 pins
Latch2 pins control a number of on-board devices, namely LCD, NAND,
MODEM and CODEC. Those pins used to be initialized with safe values
from init_machine before that operation was:
1) moved to late_initcall in preparation for conversion of latch2 to
GPIO device - see commit f7519d8c8290 ("ARM:
Convert modem related GPIO setup from integer space to GPIO descriptors.
Also, restore original initialization order of the MODEM device and its
related GPIO pins.
Cleanup of MODEM relaated regulator setup is postponed while waiting for
upcoming conversion of fixed regulator API to GPIO
Depending on MACH_INGENIC prevent us from creating a generic kernel that
works on more than one MIPS board. Instead, we just depend on MIPS being
set.
Signed-off-by: Paul Cercueil
---
drivers/rtc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig
Depending on MACH_INGENIC prevent us from creating a generic kernel that
works on more than one MIPS board. Instead, we just depend on MIPS being
set.
Signed-off-by: Paul Cercueil
---
drivers/rtc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig
On Mon, Aug 20, 2018 at 12:54 PM, Moritz Fischer wrote:
> Hi Alan,
>
> On Mon, Aug 20, 2018 at 12:46:32PM -0500, Alan Tull wrote:
>> On Mon, Aug 20, 2018 at 12:18 PM, Moritz Fischer wrote:
>>
>> Hi Moritz,
>>
>> > Replace dev_get_drvdata() with platform_get_drvdata() to
>> > match the
On Mon, Aug 20, 2018 at 12:54 PM, Moritz Fischer wrote:
> Hi Alan,
>
> On Mon, Aug 20, 2018 at 12:46:32PM -0500, Alan Tull wrote:
>> On Mon, Aug 20, 2018 at 12:18 PM, Moritz Fischer wrote:
>>
>> Hi Moritz,
>>
>> > Replace dev_get_drvdata() with platform_get_drvdata() to
>> > match the
* Gautham R. Shenoy [2018-08-20 11:11:44]:
> From: "Gautham R. Shenoy"
>
> Each of the SMT4 cores forming a big-core are more or less independent
> units. Thus when multiple tasks are scheduled to run on the fused
> core, we get the best performance when the tasks are spread across the
> pair
* Gautham R. Shenoy [2018-08-20 11:11:44]:
> From: "Gautham R. Shenoy"
>
> Each of the SMT4 cores forming a big-core are more or less independent
> units. Thus when multiple tasks are scheduled to run on the fused
> core, we get the best performance when the tasks are spread across the
> pair
On Mon, Aug 20, 2018 at 06:29:38PM +0200, Michal Hocko wrote:
> On Fri 17-08-18 15:27:33, Guenter Roeck wrote:
> > Hi,
> >
> > the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> > with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
>
> Could you
On Mon, Aug 20, 2018 at 06:29:38PM +0200, Michal Hocko wrote:
> On Fri 17-08-18 15:27:33, Guenter Roeck wrote:
> > Hi,
> >
> > the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> > with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
>
> Could you
On Sun, 2018-08-19 at 13:34 +0200, Greg Kroah-Hartman wrote:
> On Sun, Aug 19, 2018 at 03:35:02PM +0530, Nishad Kamdar wrote:
> > Fixed four debug macros and their usages. Replaced printk with
> > dev_ without __func__ or __LINE__ or current->comm and
> > current->pid. Further removed the do {}
On Sun, 2018-08-19 at 13:34 +0200, Greg Kroah-Hartman wrote:
> On Sun, Aug 19, 2018 at 03:35:02PM +0530, Nishad Kamdar wrote:
> > Fixed four debug macros and their usages. Replaced printk with
> > dev_ without __func__ or __LINE__ or current->comm and
> > current->pid. Further removed the do {}
On Fri, 17 Aug 2018 10:15:27 -0500, Dan Murphy wrote:
> Add the device tree bindings for the lm3697
> LED driver for backlighting and display.
>
> Signed-off-by: Dan Murphy
> ---
>
> v5 - Fix the comment for the example -
> https://lore.kernel.org/patchwork/patch/975060/
>
> v4 - Removed
On Fri, 17 Aug 2018 10:15:27 -0500, Dan Murphy wrote:
> Add the device tree bindings for the lm3697
> LED driver for backlighting and display.
>
> Signed-off-by: Dan Murphy
> ---
>
> v5 - Fix the comment for the example -
> https://lore.kernel.org/patchwork/patch/975060/
>
> v4 - Removed
Hi Alan,
On Mon, Aug 20, 2018 at 12:46:32PM -0500, Alan Tull wrote:
> On Mon, Aug 20, 2018 at 12:18 PM, Moritz Fischer wrote:
>
> Hi Moritz,
>
> > Replace dev_get_drvdata() with platform_get_drvdata() to
> > match the platform_set_drvdata() in the probe function of
> > the platform driver.
> >
Hi Alan,
On Mon, Aug 20, 2018 at 12:46:32PM -0500, Alan Tull wrote:
> On Mon, Aug 20, 2018 at 12:18 PM, Moritz Fischer wrote:
>
> Hi Moritz,
>
> > Replace dev_get_drvdata() with platform_get_drvdata() to
> > match the platform_set_drvdata() in the probe function of
> > the platform driver.
> >
Hi Ted,
On Mon, Aug 20, 2018 at 2:02 AM, Theodore Y. Ts'o wrote:
> P.S. It's really, really too bad there isn't a simpler way to shut up
> gcc. You need the #ifdef __GNUC_PREREQ nonsense because otherwise
> older versions of gcc that don't understand the particular warning
> you're trying to
On Mon, Aug 20, 2018 at 12:18 PM, Moritz Fischer wrote:
Hi Moritz,
> Replace dev_get_drvdata() with platform_get_drvdata() to
> match the platform_set_drvdata() in the probe function of
> the platform driver.
>
> Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for
>
Hi Ted,
On Mon, Aug 20, 2018 at 2:02 AM, Theodore Y. Ts'o wrote:
> P.S. It's really, really too bad there isn't a simpler way to shut up
> gcc. You need the #ifdef __GNUC_PREREQ nonsense because otherwise
> older versions of gcc that don't understand the particular warning
> you're trying to
On Mon, Aug 20, 2018 at 12:18 PM, Moritz Fischer wrote:
Hi Moritz,
> Replace dev_get_drvdata() with platform_get_drvdata() to
> match the platform_set_drvdata() in the probe function of
> the platform driver.
>
> Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for
>
I think we should take Joe's patch.
Reviewed-by: Nick Desaulniers
(sorry for the lack of context, trying out the reply instructions from:
https://lore.kernel.org/lkml/4cdd4ab9ddd16f1fb168266643264595782fd890.ca...@perches.com/)
I think we should take Joe's patch.
Reviewed-by: Nick Desaulniers
(sorry for the lack of context, trying out the reply instructions from:
https://lore.kernel.org/lkml/4cdd4ab9ddd16f1fb168266643264595782fd890.ca...@perches.com/)
On 8/20/2018 4:21 AM, Lukas Wunner wrote:
On Fri, Aug 17, 2018 at 11:51:10PM -0700, Sinan Kaya wrote:
+static int pciehp_control_surprise_error(struct controller *ctrl, bool enable)
The return value isn't checked, so this could return void.
Sure, I can do that.
@@ -280,6 +303,9 @@
On 8/20/2018 4:21 AM, Lukas Wunner wrote:
On Fri, Aug 17, 2018 at 11:51:10PM -0700, Sinan Kaya wrote:
+static int pciehp_control_surprise_error(struct controller *ctrl, bool enable)
The return value isn't checked, so this could return void.
Sure, I can do that.
@@ -280,6 +303,9 @@
On 08/20/2018 10:23 AM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:09 -0400
Tony Krowiak wrote:
From: Tony Krowiak
Provides the sysfs interfaces for:
1. Assigning AP control domains to the mediated matrix device
2. Unassigning AP control domains from a mediated matrix device
3.
On 08/20/2018 10:23 AM, Cornelia Huck wrote:
On Mon, 13 Aug 2018 17:48:09 -0400
Tony Krowiak wrote:
From: Tony Krowiak
Provides the sysfs interfaces for:
1. Assigning AP control domains to the mediated matrix device
2. Unassigning AP control domains from a mediated matrix device
3.
I am testing the patch set with the following code:
#include
#include
volatile short semaphore = 0;
int for_uprobe(int c)
{
printf("%d\n", c + 10);
return c + 1;
}
int main(int argc, char *argv[])
{
for_uprobe(argc);
while (1) {
sleep(1);
On Mon, Aug 20, 2018 at 04:41:16PM +0200, Michal Hocko wrote:
> > +++ b/fs/xfs/xfs_buf.c
> > for (i = 0; i < bp->b_page_count; i++) {
> > - bp->b_pages[i] = mem_to_page((void *)pageaddr);
> > + bp->b_pages[i] = kvvirt_to_page((void *)pageaddr);
> > pageaddr +=
I am testing the patch set with the following code:
#include
#include
volatile short semaphore = 0;
int for_uprobe(int c)
{
printf("%d\n", c + 10);
return c + 1;
}
int main(int argc, char *argv[])
{
for_uprobe(argc);
while (1) {
sleep(1);
On Mon, Aug 20, 2018 at 04:41:16PM +0200, Michal Hocko wrote:
> > +++ b/fs/xfs/xfs_buf.c
> > for (i = 0; i < bp->b_page_count; i++) {
> > - bp->b_pages[i] = mem_to_page((void *)pageaddr);
> > + bp->b_pages[i] = kvvirt_to_page((void *)pageaddr);
> > pageaddr +=
On Mon, Aug 20, 2018 at 12:59:05PM -0400, Sinan Kaya wrote:
> On 8/20/2018 5:22 AM, Lukas Wunner wrote:
> > > +
> > This differs from v7 of the patch in that*any* fatal error, not just
> > a Surprise Link Down, results in pciehp waiting for the error to clear.
> >
> > I'm wondering if that's
On Mon, Aug 20, 2018 at 12:59:05PM -0400, Sinan Kaya wrote:
> On 8/20/2018 5:22 AM, Lukas Wunner wrote:
> > > +
> > This differs from v7 of the patch in that*any* fatal error, not just
> > a Surprise Link Down, results in pciehp waiting for the error to clear.
> >
> > I'm wondering if that's
201 - 300 of 844 matches
Mail list logo
