On 05/30/2018 08:00 PM, Jon Hunter wrote:
>>> My only other comments on this series are ...
>>>
>>> 1. I think it would be nice to have an dev_pm_domain_attach_by_name() and
>>>that the DT binding has a 'power-domain-names' property.
>> I think it makes sense, but my plan was to do that as
Using the sysfs unbind, bind nodes, mxcnd_probe and mxcnd_probe_dt can
potentially be called at any time. After the __init functions are cleaned,
mxcnd_probe_dt is no longer available. Calling it anyway causes a crash.
mxcnd_probe used to be marked as __init, this was removed years ago.
Remove
On 05/30/2018 08:00 PM, Jon Hunter wrote:
>>> My only other comments on this series are ...
>>>
>>> 1. I think it would be nice to have an dev_pm_domain_attach_by_name() and
>>>that the DT binding has a 'power-domain-names' property.
>> I think it makes sense, but my plan was to do that as
Using the sysfs unbind, bind nodes, mxcnd_probe and mxcnd_probe_dt can
potentially be called at any time. After the __init functions are cleaned,
mxcnd_probe_dt is no longer available. Calling it anyway causes a crash.
mxcnd_probe used to be marked as __init, this was removed years ago.
Remove
On Mon, 2018-06-25 at 17:14 +0200, Matthias Brugger wrote:
>
> On 27/04/18 10:14, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > The MediaTek MT7623 SoC contains a Mali-450, so add a compatible for it
> > and define its own vendor-specific properties.
> >
> > Reviewed-by: Rob
On Mon, 2018-06-25 at 17:14 +0200, Matthias Brugger wrote:
>
> On 27/04/18 10:14, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > The MediaTek MT7623 SoC contains a Mali-450, so add a compatible for it
> > and define its own vendor-specific properties.
> >
> > Reviewed-by: Rob
On 6/27/2018 1:45 PM, Andy Lutomirski wrote:
Commit 8bb2610bc496 ("x86/entry/64/compat: Preserve r8-r11 in int
$0x80") was busted. My original patch had a minor conflict with
some of the nospec changes. git apply is very clever and silently
accepted the patch by making the same changes to a
kbuild test robot writes:
> All errors (new ones prefixed by >>):
>
>drivers/clk/pxa/clk-pxa25x.c: In function 'pxa25x_register_plls':
>>> drivers/clk/pxa/clk-pxa25x.c:298:17: error: expected ')' before ';' token
> 32768);
> ^
>>>
On 6/27/2018 1:45 PM, Andy Lutomirski wrote:
Commit 8bb2610bc496 ("x86/entry/64/compat: Preserve r8-r11 in int
$0x80") was busted. My original patch had a minor conflict with
some of the nospec changes. git apply is very clever and silently
accepted the patch by making the same changes to a
kbuild test robot writes:
> All errors (new ones prefixed by >>):
>
>drivers/clk/pxa/clk-pxa25x.c: In function 'pxa25x_register_plls':
>>> drivers/clk/pxa/clk-pxa25x.c:298:17: error: expected ')' before ';' token
> 32768);
> ^
>>>
On Wed, Jun 27, 2018 at 12:18:37AM +0200, Jirka Hladky wrote:
> Hi Mel,
>
> we have results for the "Fixes for sched/numa_balancing" series and overall
> it looks very promising.
>
> We see improvements in the range 15-20% for the stream benchmark and
> upto 60% for the OpenMP NAS benchmark.
On Wed, Jun 27, 2018 at 12:18:37AM +0200, Jirka Hladky wrote:
> Hi Mel,
>
> we have results for the "Fixes for sched/numa_balancing" series and overall
> it looks very promising.
>
> We see improvements in the range 15-20% for the stream benchmark and
> upto 60% for the OpenMP NAS benchmark.
On 27/06/2018 08:42:17+, Ben Whitten wrote:
> Hi Alexandre,
>
> As you are planning a clock binding rework and this patch in the series
> needs a change to account for that, do you want me to re-submit after
> your series or are we good to go as is?
>
No change needed from you, I'll take
On 27/06/2018 08:42:17+, Ben Whitten wrote:
> Hi Alexandre,
>
> As you are planning a clock binding rework and this patch in the series
> needs a change to account for that, do you want me to re-submit after
> your series or are we good to go as is?
>
No change needed from you, I'll take
On 26.06.2018 19:00, Mike Kravetz wrote:
> On 06/26/2018 06:24 AM, Janosch Frank wrote:
>> Use huge_ptep_get to translate huge ptes to normal ptes so we can
>> check them with the huge_pte_* functions. Otherwise some architectures
>> will check the wrong values and will not wait for userspace to
On 26.06.2018 19:00, Mike Kravetz wrote:
> On 06/26/2018 06:24 AM, Janosch Frank wrote:
>> Use huge_ptep_get to translate huge ptes to normal ptes so we can
>> check them with the huge_pte_* functions. Otherwise some architectures
>> will check the wrong values and will not wait for userspace to
Hi Nishanth,
On Tue, Jun 19, 2018 at 9:45 PM Nishanth Menon wrote:
> Texas Instrument's System Control Interface (TISCI) permits
> the ability for OSs running in virtual machines to be able to
> independently communicate with the firmware without the need going
> through an hypervisor.
>
> The
Hi Nishanth,
On Tue, Jun 19, 2018 at 9:45 PM Nishanth Menon wrote:
> Texas Instrument's System Control Interface (TISCI) permits
> the ability for OSs running in virtual machines to be able to
> independently communicate with the firmware without the need going
> through an hypervisor.
>
> The
There are several FUSE filesystems that can implement server-side copy
or other efficient copy/duplication/clone methods. The copy_file_range()
syscall is the standard interface that users have access to while not
depending on external libraries that bypass FUSE.
Signed-off-by: Niels de Vos
---
There are several FUSE filesystems that can implement server-side copy
or other efficient copy/duplication/clone methods. The copy_file_range()
syscall is the standard interface that users have access to while not
depending on external libraries that bypass FUSE.
Signed-off-by: Niels de Vos
---
@@ -652,6 +653,7 @@ blk_status_t nvme_setup_cmd(struct nvme_ns *ns, struct
request *req,
}
cmd->common.command_id = req->tag;
+ nvme_req(req)->ctrl = ctrl;
if (ns)
trace_nvme_setup_nvm_cmd(req->q->id, cmd);
else
I don't think we need to
@@ -652,6 +653,7 @@ blk_status_t nvme_setup_cmd(struct nvme_ns *ns, struct
request *req,
}
cmd->common.command_id = req->tag;
+ nvme_req(req)->ctrl = ctrl;
if (ns)
trace_nvme_setup_nvm_cmd(req->q->id, cmd);
else
I don't think we need to
Hi Alexandre,
As you are planning a clock binding rework and this patch in the series
needs a change to account for that, do you want me to re-submit after
your series or are we good to go as is?
Thanks,
Ben
> This adds support for Lairds CPU module, featuring Atheros wifi, CSR
> Bluetooth
Hi Alexandre,
As you are planning a clock binding rework and this patch in the series
needs a change to account for that, do you want me to re-submit after
your series or are we good to go as is?
Thanks,
Ben
> This adds support for Lairds CPU module, featuring Atheros wifi, CSR
> Bluetooth
On i.MX6SLL EVK board, SD3 slot can be used for
WiFi and other SD accessories, enable it.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6sll-evk.dts | 65 +++
1 file changed, 65 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sll-evk.dts
On i.MX6SLL EVK board, SD3 slot can be used for
WiFi and other SD accessories, enable it.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6sll-evk.dts | 65 +++
1 file changed, 65 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sll-evk.dts
Hello Stephen,
On Mon, Jun 25, 2018 at 04:46:24PM -0700, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2018-06-13 06:03:38)
> > On Tue, Jun 12, 2018 at 11:23:54AM +0300, Matti Vaittinen wrote:
> > >
> > > I see. This makes sense. I need to verify from HW colleagues whether
> > > this chip has
Hello Stephen,
On Mon, Jun 25, 2018 at 04:46:24PM -0700, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2018-06-13 06:03:38)
> > On Tue, Jun 12, 2018 at 11:23:54AM +0300, Matti Vaittinen wrote:
> > >
> > > I see. This makes sense. I need to verify from HW colleagues whether
> > > this chip has
Hi Wei,
On 26/06/18 18:47, Will Deacon wrote:
> On Wed, Jun 27, 2018 at 01:16:44AM +0800, Wei Xu wrote:
>> [0.00] Booting Linux on physical CPU 0x00 [0x480fd010]
>> [0.00] Linux version 4.18.0-rc2-58583-g7daf201-dirty
>
> I'm still suspicious that this is 4.18-rc2
Hi Wei,
On 26/06/18 18:47, Will Deacon wrote:
> On Wed, Jun 27, 2018 at 01:16:44AM +0800, Wei Xu wrote:
>> [0.00] Booting Linux on physical CPU 0x00 [0x480fd010]
>> [0.00] Linux version 4.18.0-rc2-58583-g7daf201-dirty
>
> I'm still suspicious that this is 4.18-rc2
On Tue, Jun 26, 2018 at 04:40:04PM -0700, Paul E. McKenney wrote:
> The options I have considered are as follows:
>
> 1.Stick with the no-failsafe approach, adding the lock as shown
> in this patch. (I obviously prefer this approach.)
>
> 2.Stick with the no-failsafe approach, but
On Tue, Jun 26, 2018 at 04:40:04PM -0700, Paul E. McKenney wrote:
> The options I have considered are as follows:
>
> 1.Stick with the no-failsafe approach, adding the lock as shown
> in this patch. (I obviously prefer this approach.)
>
> 2.Stick with the no-failsafe approach, but
On Tue, Jun 26, 2018 at 10:32:09PM +0200, Michael Straube wrote:
>
> On 06/26/18 22:17, Joe Perches wrote:
> > On Tue, 2018-06-26 at 21:44 +0200, Michael Straube wrote:
> > > On 06/26/18 19:32, Andy Shevchenko wrote:
> > > > On Tue, Jun 26, 2018 at 11:14 AM, Michael Straube
> > > > wrote:
> > >
On Tue, Jun 26, 2018 at 10:32:09PM +0200, Michael Straube wrote:
>
> On 06/26/18 22:17, Joe Perches wrote:
> > On Tue, 2018-06-26 at 21:44 +0200, Michael Straube wrote:
> > > On 06/26/18 19:32, Andy Shevchenko wrote:
> > > > On Tue, Jun 26, 2018 at 11:14 AM, Michael Straube
> > > > wrote:
> > >
/commits/Niels-de-Vos/fuse-add-support-for-copy_file_range/20180627-155404
base: https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
for-next
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https
/commits/Niels-de-Vos/fuse-add-support-for-copy_file_range/20180627-155404
base: https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
for-next
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https
/commits/Niels-de-Vos/fuse-add-support-for-copy_file_range/20180627-155404
base: https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
for-next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget
https
/commits/Niels-de-Vos/fuse-add-support-for-copy_file_range/20180627-155404
base: https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
for-next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget
https
On 27/06/2018 09:53, Stanley Chu wrote:
> Add binding documentation for the System Timer driver of
> the Mediatek SoCs.
>
> Signed-off-by: Stanley Chu
> ---
> .../bindings/timer/mediatek,mtk-systimer.txt | 18 ++
> 1 file changed, 18 insertions(+)
> create mode 100644
On 27/06/2018 09:53, Stanley Chu wrote:
> Add binding documentation for the System Timer driver of
> the Mediatek SoCs.
>
> Signed-off-by: Stanley Chu
> ---
> .../bindings/timer/mediatek,mtk-systimer.txt | 18 ++
> 1 file changed, 18 insertions(+)
> create mode 100644
2018-06-27 7:46 GMT+02:00 :
> From: Alan Chiang
>
> The AT24 series chips use 8-bit address by default. If some
> chips would like to support more than 8 bits, the at24 driver
> should be added the compatible field for specfic chips.
>
> Provide a flexible way to determine the addressing bits
2018-06-27 7:46 GMT+02:00 :
> From: Alan Chiang
>
> The AT24 series chips use 8-bit address by default. If some
> chips would like to support more than 8 bits, the at24 driver
> should be added the compatible field for specfic chips.
>
> Provide a flexible way to determine the addressing bits
Not related to your patch, but I did notice that the req->q->id isn't
really useful here since that's not the hardware context identifier.
That's just some ida assigned software identifier. For the admin command
completion trace, it's actually a little confusing to see the qid in the
trace.
Not related to your patch, but I did notice that the req->q->id isn't
really useful here since that's not the hardware context identifier.
That's just some ida assigned software identifier. For the admin command
completion trace, it's actually a little confusing to see the qid in the
trace.
Dear Joanne.
jdow - 27.06.18, 08:24:
> You allergic to using a GPT solution? It will get away from some of
> the evils that RDB has inherent in it because they are also features?
> (Loading a filesystem or DriveInit code from RDBs is just asking for
> a nearly impossible to remove malware
Dear Joanne.
jdow - 27.06.18, 08:24:
> You allergic to using a GPT solution? It will get away from some of
> the evils that RDB has inherent in it because they are also features?
> (Loading a filesystem or DriveInit code from RDBs is just asking for
> a nearly impossible to remove malware
On 27 June 2018 at 07:43, wrote:
> From: Sean Wang
>
> In order to open up the required power gate before any operation can be
> effectively performed over the serial bus between CPU and serdev, it's
> clearly essential to add common attach functions for PM domains to serdev
> at the probe
On 27 June 2018 at 07:43, wrote:
> From: Sean Wang
>
> In order to open up the required power gate before any operation can be
> effectively performed over the serial bus between CPU and serdev, it's
> clearly essential to add common attach functions for PM domains to serdev
> at the probe
On Wed, Jun 27, 2018 at 01:46:24PM +0800, alanx.chi...@intel.com wrote:
> From: Alan Chiang
>
> The AT24 series chips use 8-bit address by default. If some
> chips would like to support more than 8 bits, the at24 driver
> should be added the compatible field for specfic chips.
>
> Provide a
On Wed, Jun 27, 2018 at 01:46:24PM +0800, alanx.chi...@intel.com wrote:
> From: Alan Chiang
>
> The AT24 series chips use 8-bit address by default. If some
> chips would like to support more than 8 bits, the at24 driver
> should be added the compatible field for specfic chips.
>
> Provide a
Michael Schmitz - 27.06.18, 03:07:
> Joanne,
>
> As far as I have been able to test, the change is backwards compatible
> (RDB partitions from an old disk 80 GB disk are still recognized OK).
> That"s only been done on an emulator though.
>
> Your advice about the dangers of using RDB disks that
Michael Schmitz - 27.06.18, 03:07:
> Joanne,
>
> As far as I have been able to test, the change is backwards compatible
> (RDB partitions from an old disk 80 GB disk are still recognized OK).
> That"s only been done on an emulator though.
>
> Your advice about the dangers of using RDB disks that
On Wed 27-06-18 09:50:01, Vlastimil Babka wrote:
> On 06/27/2018 09:34 AM, Michal Hocko wrote:
> > On Tue 26-06-18 10:04:16, Andrew Morton wrote:
> >
> > And as I've argued before the code would be wrong regardless. We would
> > leak the memory or worse touch somebody's else kmap without knowing
On Wed 27-06-18 09:50:01, Vlastimil Babka wrote:
> On 06/27/2018 09:34 AM, Michal Hocko wrote:
> > On Tue 26-06-18 10:04:16, Andrew Morton wrote:
> >
> > And as I've argued before the code would be wrong regardless. We would
> > leak the memory or worse touch somebody's else kmap without knowing
This patch adds a new driver for system timer on the Mediatek SoCs.
Changes since v1:
- Use timer_of structure and APIs to make driver more clean.
- Remove unnecessary headers.
- Use fixed-clock.
- Fix indent.
Stanley Chu (2):
dt-bindings: Add mtk-systimer bindings
This patch adds a new clock event for the timer
found on the Mediatek SoCs.
The Mediatek System Timer has several 32-bit timers.
Only one timer is used by this driver as a clock event
supporting oneshot events.
The System Timer can be run with two clocks. A 13 MHz system
clock and the RTC clock
This patch adds a new driver for system timer on the Mediatek SoCs.
Changes since v1:
- Use timer_of structure and APIs to make driver more clean.
- Remove unnecessary headers.
- Use fixed-clock.
- Fix indent.
Stanley Chu (2):
dt-bindings: Add mtk-systimer bindings
This patch adds a new clock event for the timer
found on the Mediatek SoCs.
The Mediatek System Timer has several 32-bit timers.
Only one timer is used by this driver as a clock event
supporting oneshot events.
The System Timer can be run with two clocks. A 13 MHz system
clock and the RTC clock
Add binding documentation for the System Timer driver of
the Mediatek SoCs.
Signed-off-by: Stanley Chu
---
.../bindings/timer/mediatek,mtk-systimer.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644
Add binding documentation for the System Timer driver of
the Mediatek SoCs.
Signed-off-by: Stanley Chu
---
.../bindings/timer/mediatek,mtk-systimer.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644
Hi Tudor,
Thank you very much for comments.
On Tue, 26 Jun 2018, Tudor Ambarus wrote:
Hi, Piotr,
General things to consider for the limitation in performance:
- is the serial flash memory operating in Quad SPI?
Yes, I've checked signal using logic analyzer, data is transferred using
all
Hi Tudor,
Thank you very much for comments.
On Tue, 26 Jun 2018, Tudor Ambarus wrote:
Hi, Piotr,
General things to consider for the limitation in performance:
- is the serial flash memory operating in Quad SPI?
Yes, I've checked signal using logic analyzer, data is transferred using
all
On 06/27/2018 09:34 AM, Michal Hocko wrote:
> On Tue 26-06-18 10:04:16, Andrew Morton wrote:
>
> And as I've argued before the code would be wrong regardless. We would
> leak the memory or worse touch somebody's else kmap without knowing
> that. So we have a choice between a mem leak, data
On 06/27/2018 09:34 AM, Michal Hocko wrote:
> On Tue 26-06-18 10:04:16, Andrew Morton wrote:
>
> And as I've argued before the code would be wrong regardless. We would
> leak the memory or worse touch somebody's else kmap without knowing
> that. So we have a choice between a mem leak, data
Hi
On 06/26/2018 07:58 PM, Jae Hyun Yoo wrote:
BMC firmware should support some multi-master use cases such as multi-node,
IPMB, BMC-ME link and so on but the current ASPEED I2C driver is a bit
unstable for the multi-master use case. So this patch improves ASPEED I2C
driver to support the
Hi
On 06/26/2018 07:58 PM, Jae Hyun Yoo wrote:
BMC firmware should support some multi-master use cases such as multi-node,
IPMB, BMC-ME link and so on but the current ASPEED I2C driver is a bit
unstable for the multi-master use case. So this patch improves ASPEED I2C
driver to support the
On Wed, Jun 27, 2018 at 01:46:25PM +0800, alanx.chi...@intel.com wrote:
> From: Alan Chiang
>
> Provide a flexible way to determine the addressing bits of eeprom.
> Pass the addressing bits to driver through address-width property.
>
> Signed-off-by: Alan Chiang
> Signed-off-by: Andy Yeh
>
>
There are several FUSE filesystems that can implement server-side copy
or other efficient copy/duplication/clone methods. The copy_file_range()
syscall is the standard interface that users have access to while not
depending on external libraries that bypass FUSE.
Signed-off-by: Niels de Vos
---
There are several FUSE filesystems that can implement server-side copy
or other efficient copy/duplication/clone methods. The copy_file_range()
syscall is the standard interface that users have access to while not
depending on external libraries that bypass FUSE.
Signed-off-by: Niels de Vos
---
On Wed, Jun 27, 2018 at 01:46:25PM +0800, alanx.chi...@intel.com wrote:
> From: Alan Chiang
>
> Provide a flexible way to determine the addressing bits of eeprom.
> Pass the addressing bits to driver through address-width property.
>
> Signed-off-by: Alan Chiang
> Signed-off-by: Andy Yeh
>
>
Add the tas5707 to the available compatibles of the tas571x driver
Signed-off-by: Jerome Brunet
---
Documentation/devicetree/bindings/sound/tas571x.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sound/tas571x.txt
Add support for the tas5707 audio power amplifier.
Signed-off-by: Jerome Brunet
---
sound/soc/codecs/Kconfig | 5 ++-
sound/soc/codecs/tas571x.c | 110 +
sound/soc/codecs/tas571x.h | 16 +++
3 files changed, 130 insertions(+), 1 deletion(-)
Add the tas5707 to the available compatibles of the tas571x driver
Signed-off-by: Jerome Brunet
---
Documentation/devicetree/bindings/sound/tas571x.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sound/tas571x.txt
Add support for the tas5707 audio power amplifier.
Signed-off-by: Jerome Brunet
---
sound/soc/codecs/Kconfig | 5 ++-
sound/soc/codecs/tas571x.c | 110 +
sound/soc/codecs/tas571x.h | 16 +++
3 files changed, 130 insertions(+), 1 deletion(-)
This patchset extends the tas571x driver to support the tas5707
audio power amplifier.
Jerome Brunet (2):
ASoC: tas571x: add tas5707 compatible
ASoC: tas517x: add tas5707 support
Changes since v1 [0]:
* Fixed double const as reported by kbuild robot [1]
[0]:
This patchset extends the tas571x driver to support the tas5707
audio power amplifier.
Jerome Brunet (2):
ASoC: tas571x: add tas5707 compatible
ASoC: tas517x: add tas5707 support
Changes since v1 [0]:
* Fixed double const as reported by kbuild robot [1]
[0]:
On Wed 27-06-18 09:34:20, Michal Hocko wrote:
> On Tue 26-06-18 10:04:16, Andrew Morton wrote:
[...]
> > Really, the changelog isn't right. There *is* a real reason to blow
> > up. Effectively the caller is attempting to obtain the virtual address
> > of a highmem page without having kmapped it
On Wed 27-06-18 09:34:20, Michal Hocko wrote:
> On Tue 26-06-18 10:04:16, Andrew Morton wrote:
[...]
> > Really, the changelog isn't right. There *is* a real reason to blow
> > up. Effectively the caller is attempting to obtain the virtual address
> > of a highmem page without having kmapped it
On Tue, Jun 26, 2018 at 9:58 AM Jae Hyun Yoo
wrote:
>
> BMC firmware should support some multi-master use cases such as multi-node,
> IPMB, BMC-ME link and so on but the current ASPEED I2C driver is a bit
> unstable for the multi-master use case. So this patch improves ASPEED I2C
> driver to
On Tue, Jun 26, 2018 at 9:58 AM Jae Hyun Yoo
wrote:
>
> BMC firmware should support some multi-master use cases such as multi-node,
> IPMB, BMC-ME link and so on but the current ASPEED I2C driver is a bit
> unstable for the multi-master use case. So this patch improves ASPEED I2C
> driver to
gpio_keys.h uses 'bool' - type which is defined in linux/types.h.
Include this header.
Signed-off-by: Matti Vaittinen
---
include/linux/gpio_keys.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/gpio_keys.h b/include/linux/gpio_keys.h
index 7160df54a6fe..3f84aeb81e48 100644
gpio_keys.h uses 'bool' - type which is defined in linux/types.h.
Include this header.
Signed-off-by: Matti Vaittinen
---
include/linux/gpio_keys.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/gpio_keys.h b/include/linux/gpio_keys.h
index 7160df54a6fe..3f84aeb81e48 100644
On Tue, Jun 26, 2018 at 08:55:32AM -0600, Keith Busch wrote:
> On Tue, Jun 26, 2018 at 03:51:40PM +0200, Johannes Thumshirn wrote:
> > @@ -652,6 +653,7 @@ blk_status_t nvme_setup_cmd(struct nvme_ns *ns, struct
> > request *req,
> > }
> >
> > cmd->common.command_id = req->tag;
> > +
On Tue, Jun 26, 2018 at 08:55:32AM -0600, Keith Busch wrote:
> On Tue, Jun 26, 2018 at 03:51:40PM +0200, Johannes Thumshirn wrote:
> > @@ -652,6 +653,7 @@ blk_status_t nvme_setup_cmd(struct nvme_ns *ns, struct
> > request *req,
> > }
> >
> > cmd->common.command_id = req->tag;
> > +
On Tue 26-06-18 10:04:16, Andrew Morton wrote:
> On Tue, 26 Jun 2018 15:57:39 +0200 Vlastimil Babka wrote:
>
> > On 06/22/2018 06:28 PM, Michal Hocko wrote:
> > > From: Michal Hocko
> > >
> > > There is no real reason to blow up just because the caller doesn't know
> > > that __get_free_pages
On Tue 26-06-18 10:04:16, Andrew Morton wrote:
> On Tue, 26 Jun 2018 15:57:39 +0200 Vlastimil Babka wrote:
>
> > On 06/22/2018 06:28 PM, Michal Hocko wrote:
> > > From: Michal Hocko
> > >
> > > There is no real reason to blow up just because the caller doesn't know
> > > that __get_free_pages
On Tue, Jun 26, 2018 at 09:01:06AM -0600, Keith Busch wrote:
> Not related to your patch, but I did notice that the req->q->id isn't
> really useful here since that's not the hardware context identifier.
> That's just some ida assigned software identifier. For the admin command
> completion trace,
On Tue, Jun 26, 2018 at 09:01:06AM -0600, Keith Busch wrote:
> Not related to your patch, but I did notice that the req->q->id isn't
> really useful here since that's not the hardware context identifier.
> That's just some ida assigned software identifier. For the admin command
> completion trace,
On Tue 26-06-18 12:07:57, Shakeel Butt wrote:
> On Tue, Jun 26, 2018 at 11:55 AM Johannes Weiner wrote:
> >
> > On Tue, Jun 26, 2018 at 11:00:53AM -0700, Shakeel Butt wrote:
> > > On Mon, Jun 25, 2018 at 10:49 PM Amir Goldstein
> > > wrote:
> > > >
> > > ...
> > > >
> > > > The verb 'unuse'
On Tue 26-06-18 12:07:57, Shakeel Butt wrote:
> On Tue, Jun 26, 2018 at 11:55 AM Johannes Weiner wrote:
> >
> > On Tue, Jun 26, 2018 at 11:00:53AM -0700, Shakeel Butt wrote:
> > > On Mon, Jun 25, 2018 at 10:49 PM Amir Goldstein
> > > wrote:
> > > >
> > > ...
> > > >
> > > > The verb 'unuse'
On Tue 26-06-18 18:03:34, Yang Shi wrote:
>
>
> On 6/26/18 12:43 AM, Peter Zijlstra wrote:
> > On Mon, Jun 25, 2018 at 05:06:23PM -0700, Yang Shi wrote:
> > > By looking this deeper, we may not be able to cover all the unmapping
> > > range
> > > for VM_DEAD, for example, if the start addr is
On Tue 26-06-18 18:03:34, Yang Shi wrote:
>
>
> On 6/26/18 12:43 AM, Peter Zijlstra wrote:
> > On Mon, Jun 25, 2018 at 05:06:23PM -0700, Yang Shi wrote:
> > > By looking this deeper, we may not be able to cover all the unmapping
> > > range
> > > for VM_DEAD, for example, if the start addr is
On Tue 26-06-18 10:03:45, Paul E. McKenney wrote:
[...]
> 3.Something else?
How hard it would be to use a different API than oom notifiers? E.g. a
shrinker which just kicks all the pending callbacks if the reclaim
priority reaches low values (e.g. 0)?
--
Michal Hocko
SUSE Labs
On Tue 26-06-18 10:03:45, Paul E. McKenney wrote:
[...]
> 3.Something else?
How hard it would be to use a different API than oom notifiers? E.g. a
shrinker which just kicks all the pending callbacks if the reclaim
priority reaches low values (e.g. 0)?
--
Michal Hocko
SUSE Labs
This smells like an issue Naoya was seeing I guess (Cced)
On Tue 26-06-18 17:41:52, Herton R. Krzesinski wrote:
> Hi,
>
> While running proc01 test from ltp, or as I later found out if you just read
> kpagecount ("cat /proc/kpagecount > /dev/null"), I started to get the
> following
> oops on
This smells like an issue Naoya was seeing I guess (Cced)
On Tue 26-06-18 17:41:52, Herton R. Krzesinski wrote:
> Hi,
>
> While running proc01 test from ltp, or as I later found out if you just read
> kpagecount ("cat /proc/kpagecount > /dev/null"), I started to get the
> following
> oops on
> + i2c_gpio: i2c-gpio {
> + compatible = "i2c-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <_swi2c>;
> + i2c-gpio,delay-us = <50>;
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells =
> + i2c_gpio: i2c-gpio {
> + compatible = "i2c-gpio";
> + pinctrl-names = "default";
> + pinctrl-0 = <_swi2c>;
> + i2c-gpio,delay-us = <50>;
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells =
On Tue, Jun 26, 2018 at 10:32 PM, Bjorn Helgaas wrote:
> On Tue, Jun 26, 2018 at 07:19:29PM +0200, Rafael J. Wysocki wrote:
>> On Tue, Jun 26, 2018 at 7:14 PM, Bjorn Helgaas wrote:
>> > On Tue, Jun 26, 2018 at 04:22:00PM +0200, Rafael J. Wysocki wrote:
>> >> On Tue, Jun 26, 2018 at 4:01 PM,
On Tue, Jun 26, 2018 at 10:32 PM, Bjorn Helgaas wrote:
> On Tue, Jun 26, 2018 at 07:19:29PM +0200, Rafael J. Wysocki wrote:
>> On Tue, Jun 26, 2018 at 7:14 PM, Bjorn Helgaas wrote:
>> > On Tue, Jun 26, 2018 at 04:22:00PM +0200, Rafael J. Wysocki wrote:
>> >> On Tue, Jun 26, 2018 at 4:01 PM,
901 - 1000 of 1028 matches
Mail list logo
