Add gpio nodes for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 51 +++
1 file changed, 51 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
Add gpio nodes for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 51 +++
1 file changed, 51 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
index
Add S900 pinctrl and gpio entries under ARCH_ACTIONS
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 4
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 640dabc4c311..d63793ee545e 100644
--- a/MAINTAINERS
+++
Add S900 pinctrl and gpio entries under ARCH_ACTIONS
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 4
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 640dabc4c311..d63793ee545e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1125,10 +1125,14 @@ F:
Add gpio line names to Actions Semi S900 based Bubblegum-96 board.
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Linus Walleij
---
arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 195 ++
1 file changed, 195
Add gpio driver for Actions Semi OWL family S900 SoC. Set of registers
controlling the gpio shares the same register range with pinctrl block.
GPIO registers are organized as 6 banks and each bank controls the
maximum of 32 gpios.
Signed-off-by: Manivannan Sadhasivam
Add gpio line names to Actions Semi S900 based Bubblegum-96 board.
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Linus Walleij
---
arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 195 ++
1 file changed, 195 insertions(+)
diff --git
Add gpio driver for Actions Semi OWL family S900 SoC. Set of registers
controlling the gpio shares the same register range with pinctrl block.
GPIO registers are organized as 6 banks and each bank controls the
maximum of 32 gpios.
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Andy
Since I'll be working on improving support for ACTIONS platforms, adding
myself as the reviewer.
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9a7f76eadae9..640dabc4c311
Since I'll be working on improving support for ACTIONS platforms, adding
myself as the reviewer.
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9a7f76eadae9..640dabc4c311 100644
--- a/MAINTAINERS
+++
On 04/03/2018 02:12 PM, Alison Schofield wrote:
> +
> + /*
> + * topology_sane() considers LLCs that span NUMA nodes to be
> + * insane and will display a warning message. Bypass the call
> + * to topology_sane() for snc_cpu's to avoid that warning.
> + */
> +
> + if
On 04/03/2018 02:12 PM, Alison Schofield wrote:
> +
> + /*
> + * topology_sane() considers LLCs that span NUMA nodes to be
> + * insane and will display a warning message. Bypass the call
> + * to topology_sane() for snc_cpu's to avoid that warning.
> + */
> +
> + if
Add pinctrl driver for Actions Semi S900 SoC. The driver supports
pinctrl, pinmux and pinconf functionalities through a range of registers
common to both gpio driver and pinctrl driver.
Pinmux functionality is available only for the pin groups while the
pinconf functionality is available for both
Add pinctrl driver for Actions Semi S900 SoC. The driver supports
pinctrl, pinmux and pinconf functionalities through a range of registers
common to both gpio driver and pinctrl driver.
Pinmux functionality is available only for the pin groups while the
pinconf functionality is available for both
Add gpio nodes for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
.../devicetree/bindings/gpio/actions,owl-gpio.txt | 87 ++
1 file changed, 87 insertions(+)
create mode 100644
Add gpio nodes for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
.../devicetree/bindings/gpio/actions,owl-gpio.txt | 87 ++
1 file changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/actions,owl-gpio.txt
diff --git
Select PINCTRL for Actions Semi SoCs
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Linus Walleij
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms
Select PINCTRL for Actions Semi SoCs
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Linus Walleij
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index fbedbd8f619a..bae1289bdc3f 100644
---
Add pinctrl nodes for Actions Semi S900 SoC
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Linus Walleij
---
arch/arm64/boot/dts/actions/s900.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git
Add pinctrl nodes for Actions Semi S900 SoC
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Linus Walleij
---
arch/arm64/boot/dts/actions/s900.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
index
This patchset adds pinctrl and gpio support for Actions Semi S900 SoC.
Pinctrl and gpio subsystems share the common set of register range but
implemented as individual drivers for making it less complex.
Pinmux functions are only accessible for pin groups while pinconf
parameters are available
This patchset adds pinctrl and gpio support for Actions Semi S900 SoC.
Pinctrl and gpio subsystems share the common set of register range but
implemented as individual drivers for making it less complex.
Pinmux functions are only accessible for pin groups while pinconf
parameters are available
On 04/04/2018 10:48 PM, Mark Rutland wrote:
> On Wed, Apr 04, 2018 at 10:43:16PM +0530, Sandipan Das wrote:
>> Hi Mark,
>>
>> On 04/04/2018 10:04 PM, Mark Rutland wrote:
>>>
>>> Zhijian, Sandipan, does this patch work for you?
>>>
>>
>> Yes it does. Thanks for the fix.
>
> Great! Can I take
On 04/04/2018 10:48 PM, Mark Rutland wrote:
> On Wed, Apr 04, 2018 at 10:43:16PM +0530, Sandipan Das wrote:
>> Hi Mark,
>>
>> On 04/04/2018 10:04 PM, Mark Rutland wrote:
>>>
>>> Zhijian, Sandipan, does this patch work for you?
>>>
>>
>> Yes it does. Thanks for the fix.
>
> Great! Can I take
On Tue, Apr 03, 2018 at 06:58:48PM +, Luis R. Rodriguez wrote:
> On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote:
> > On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote:
> > > I asked Peter Jones for suggestions how to extract this during boot and
> > > he suggested
On Wed, Apr 04, 2018 at 10:43:16PM +0530, Sandipan Das wrote:
> Hi Mark,
>
> On 04/04/2018 10:04 PM, Mark Rutland wrote:
> >
> > Zhijian, Sandipan, does this patch work for you?
> >
>
> Yes it does. Thanks for the fix.
Great! Can I take that as a Tested-by?
Thanks,
Mark.
On Tue, Apr 03, 2018 at 06:58:48PM +, Luis R. Rodriguez wrote:
> On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote:
> > On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote:
> > > I asked Peter Jones for suggestions how to extract this during boot and
> > > he suggested
On Wed, Apr 04, 2018 at 10:43:16PM +0530, Sandipan Das wrote:
> Hi Mark,
>
> On 04/04/2018 10:04 PM, Mark Rutland wrote:
> >
> > Zhijian, Sandipan, does this patch work for you?
> >
>
> Yes it does. Thanks for the fix.
Great! Can I take that as a Tested-by?
Thanks,
Mark.
On Wed, 4 Apr 2018 18:23:05 +0200
Peter Zijlstra wrote:
>
> Makes sense, could you convert all of them just to make sure there
> aren't any left?
There's a few others. I'll send another patch.
-- Steve
On Wed, 4 Apr 2018 18:23:05 +0200
Peter Zijlstra wrote:
>
> Makes sense, could you convert all of them just to make sure there
> aren't any left?
There's a few others. I'll send another patch.
-- Steve
Hi Mark,
On 04/04/2018 10:04 PM, Mark Rutland wrote:
>
> Zhijian, Sandipan, does this patch work for you?
>
Yes it does. Thanks for the fix.
- Sandipan
Hi Mark,
On 04/04/2018 10:04 PM, Mark Rutland wrote:
>
> Zhijian, Sandipan, does this patch work for you?
>
Yes it does. Thanks for the fix.
- Sandipan
On Wed, Apr 4, 2018 at 9:49 AM, Nick Desaulniers
wrote:
>
> It's definitely something curious that I'll need to sit down and investigate
> more. If there are other known instances, it would be good to let me know.
Note that we explicitly use
On Wed, Apr 4, 2018 at 9:49 AM, Nick Desaulniers
wrote:
>
> It's definitely something curious that I'll need to sit down and investigate
> more. If there are other known instances, it would be good to let me know.
Note that we explicitly use "-fno-delete-null-pointer-checks" because
we do *not*
On Wed, 4 Apr 2018 11:34:55 +0900
Sergey Senozhatsky wrote:
> On (04/03/18 18:03), Steven Rostedt wrote:
> >
> > > he'd want you to change all the trace_printk()s to %px with
> > > justifications, though.
> >
> > What trace_printk()s do you want to
On Wed, 4 Apr 2018 11:34:55 +0900
Sergey Senozhatsky wrote:
> On (04/03/18 18:03), Steven Rostedt wrote:
> >
> > > he'd want you to change all the trace_printk()s to %px with
> > > justifications, though.
> >
> > What trace_printk()s do you want to change? They are throw away
> >
On 04/04/2018 13:54, David Hildenbrand wrote:
>> +{
>> +enum emulation_result er;
>> +
>> +er = emulate_instruction(vcpu, EMULTYPE_TRAP_UD);
>> +if (er == EMULATE_USER_EXIT)
>> +return 0;
>> +if (er != EMULATE_DONE)
>> +kvm_queue_exception(vcpu, UD_VECTOR);
On 04/04/2018 13:54, David Hildenbrand wrote:
>> +{
>> +enum emulation_result er;
>> +
>> +er = emulate_instruction(vcpu, EMULTYPE_TRAP_UD);
>> +if (er == EMULATE_USER_EXIT)
>> +return 0;
>> +if (er != EMULATE_DONE)
>> +kvm_queue_exception(vcpu, UD_VECTOR);
* Arnd Bergmann [180404 10:27]:
> When CONFIG_CACHE_L2X0 is disabled, the am43xx specific suspend
> implemnentation fails to link:
>
> arch/arm/mach-omap2/sleep43xx.o: In function `get_l2cache_base':
> (.text+0x180): undefined reference to `omap4_get_l2cache_base'
>
> This adds
* Arnd Bergmann [180404 10:27]:
> When CONFIG_CACHE_L2X0 is disabled, the am43xx specific suspend
> implemnentation fails to link:
>
> arch/arm/mach-omap2/sleep43xx.o: In function `get_l2cache_base':
> (.text+0x180): undefined reference to `omap4_get_l2cache_base'
>
> This adds an #ifdef
On 02/04/2018 03:15, Peng Hao wrote:
> fix a "warning: no previous prototype".
>
> Signed-off-by: Peng Hao
> ---
> arch/x86/kvm/x86.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 18b5ca7..6621319
On 02/04/2018 03:15, Peng Hao wrote:
> fix a "warning: no previous prototype".
>
> Signed-off-by: Peng Hao
> ---
> arch/x86/kvm/x86.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 18b5ca7..6621319 100644
> ---
On Wed, Apr 04, 2018 at 05:53:04PM +0200, Paolo Bonzini wrote:
> On 01/04/2018 17:54, Stefan Fritsch wrote:
> > This is very similar to the aligned versions movaps/movapd.
..snip..
> Applied, thanks.
Should there be a corresponding test-case?
>
> Paolo
On Wed, Apr 04, 2018 at 05:53:04PM +0200, Paolo Bonzini wrote:
> On 01/04/2018 17:54, Stefan Fritsch wrote:
> > This is very similar to the aligned versions movaps/movapd.
..snip..
> Applied, thanks.
Should there be a corresponding test-case?
>
> Paolo
On 04/04/2018 15:35, Wanpeng Li wrote:
> 2018-04-04 19:59 GMT+08:00 David Hildenbrand :
>>
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index 1eb495e..a55ecef 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -146,6 +146,9 @@ bool
On 04/04/2018 15:35, Wanpeng Li wrote:
> 2018-04-04 19:59 GMT+08:00 David Hildenbrand :
>>
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index 1eb495e..a55ecef 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -146,6 +146,9 @@ bool __read_mostly
On Tue, Apr 03, 2018 at 05:59:04PM -0700, Linus Torvalds wrote:
> People hotplug ATA _controllers_? :-O
>
> As opposed to just the disks a'la eSATA?
Heh, yeah, it's surprising. IIUC, it's people trying pcie hotplug (I
don't know whether they try physically) on SAS controllers on fancy
On Tue, Apr 03, 2018 at 05:59:04PM -0700, Linus Torvalds wrote:
> People hotplug ATA _controllers_? :-O
>
> As opposed to just the disks a'la eSATA?
Heh, yeah, it's surprising. IIUC, it's people trying pcie hotplug (I
don't know whether they try physically) on SAS controllers on fancy
On Wed, Mar 21, 2018 at 07:08:06PM +, Roman Gushchin wrote:
> > On Tue, Mar 20, 2018 at 10:33:53PM +, Roman Gushchin wrote:
> > > This patch aims to address an issue in current memory.low semantics,
> > > which makes it hard to use it in a hierarchy, where some leaf memory
> > > cgroups
On Wed, Mar 21, 2018 at 07:08:06PM +, Roman Gushchin wrote:
> > On Tue, Mar 20, 2018 at 10:33:53PM +, Roman Gushchin wrote:
> > > This patch aims to address an issue in current memory.low semantics,
> > > which makes it hard to use it in a hierarchy, where some leaf memory
> > > cgroups
On Wed, Apr 4, 2018 at 1:51 AM, Martin van Es wrote:
>
> On Wednesday, April 4, 2018 10:33:16 AM CEST Jiri Kosina wrote:
> > Can I add your Tested-by: while applying the commit?
>
> That's ok.
Martin is also the reporter of the issue, I did not put down his name
because I
On Wed, Apr 4, 2018 at 1:51 AM, Martin van Es wrote:
>
> On Wednesday, April 4, 2018 10:33:16 AM CEST Jiri Kosina wrote:
> > Can I add your Tested-by: while applying the commit?
>
> That's ok.
Martin is also the reporter of the issue, I did not put down his name
because I wasn't sure if he
Hi Stefan,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16 next-20180404]
[cannot apply to battery/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi Stefan,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16 next-20180404]
[cannot apply to battery/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On 04/04/2018 13:51, David Hildenbrand wrote:
> On 04.04.2018 12:44, Arnd Bergmann wrote:
>> The local variable was newly introduced but is only accessed in one
>> place on x86_64, but not on 32-bit:
>>
>> arch/x86/kvm/vmx.c: In function 'vmx_save_host_state':
>> arch/x86/kvm/vmx.c:2175:6: error:
On 04/04/2018 13:51, David Hildenbrand wrote:
> On 04.04.2018 12:44, Arnd Bergmann wrote:
>> The local variable was newly introduced but is only accessed in one
>> place on x86_64, but not on 32-bit:
>>
>> arch/x86/kvm/vmx.c: In function 'vmx_save_host_state':
>> arch/x86/kvm/vmx.c:2175:6: error:
vmx_save_host_state has multiple ifdefs for CONFIG_X86_64 that have
no other code between them. Simplify by reducing them to a single
conditional.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/vmx.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff
vmx_save_host_state has multiple ifdefs for CONFIG_X86_64 that have
no other code between them. Simplify by reducing them to a single
conditional.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/vmx.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git
On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote:
> (re-sending as plain text)
>
> On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote:
> > There are known-bugs with building a kernel with clang right now (I
> > pointed one out a few days ago about NULL
On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote:
> (re-sending as plain text)
>
> On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote:
> > There are known-bugs with building a kernel with clang right now (I
> > pointed one out a few days ago about NULL checks being deleted from the
> >
Hello,
On Wed, Apr 04, 2018 at 04:34:47PM +0200, Michal Hocko wrote:
> > > The lazy updates are neat, but I'm a little concerned at the memory
> > > footprint. On a 64-cpu machine for example, this adds close to 9000
> > > words to struct mem_cgroup. And we really only need the accuracy for
> > >
Hello,
On Wed, Apr 04, 2018 at 04:34:47PM +0200, Michal Hocko wrote:
> > > The lazy updates are neat, but I'm a little concerned at the memory
> > > footprint. On a 64-cpu machine for example, this adds close to 9000
> > > words to struct mem_cgroup. And we really only need the accuracy for
> > >
On Mon, Apr 2, 2018 at 9:32 AM, Andrew Lunn wrote:
>> The 'use case' we have been using this in for a couple years is that
>> users who want to use this watchdog will enable it externally (we have
>> a command in the bootloader) and if enabled the kernel driver (that
>> I'm
On Mon, Apr 2, 2018 at 9:32 AM, Andrew Lunn wrote:
>> The 'use case' we have been using this in for a couple years is that
>> users who want to use this watchdog will enable it externally (we have
>> a command in the bootloader) and if enabled the kernel driver (that
>> I'm proposing here which
From: Arnd Bergmann
Date: Wed, 4 Apr 2018 18:03:41 +0200
> On Wed, Apr 4, 2018 at 5:52 PM, David Miller wrote:
>> From: Arnd Bergmann
>> Date: Wed, 4 Apr 2018 14:12:39 +0200
>>
>>> The __net_initdata section cannot currently be used for
From: Arnd Bergmann
Date: Wed, 4 Apr 2018 18:03:41 +0200
> On Wed, Apr 4, 2018 at 5:52 PM, David Miller wrote:
>> From: Arnd Bergmann
>> Date: Wed, 4 Apr 2018 14:12:39 +0200
>>
>>> The __net_initdata section cannot currently be used for structures that
>>> get cleaned up in an exitcall using
Hi Alex,
On 04/04/18 16:33, Alex G. wrote:
> On 04/04/2018 02:18 AM, James Morse wrote:
>> On 03/04/18 18:08, Alexandru Gagniuc wrote:
>>> BIOSes like to send NMIs for a number of silly reasons often deemed
>>> to be "fatal". For example pin bounce during a PCIE hotplug/unplug
>>> might cause the
Hi Alex,
On 04/04/18 16:33, Alex G. wrote:
> On 04/04/2018 02:18 AM, James Morse wrote:
>> On 03/04/18 18:08, Alexandru Gagniuc wrote:
>>> BIOSes like to send NMIs for a number of silly reasons often deemed
>>> to be "fatal". For example pin bounce during a PCIE hotplug/unplug
>>> might cause the
(re-sending as plain text)
On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote:
> There are known-bugs with building a kernel with clang right now (I
> pointed one out a few days ago about NULL checks being deleted from the
> clang output for no good reason, which really is
(re-sending as plain text)
On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote:
> There are known-bugs with building a kernel with clang right now (I
> pointed one out a few days ago about NULL checks being deleted from the
> clang output for no good reason, which really is scary for obvious
>
On Thu, Apr 05, 2018 at 12:58:46AM +0900, Tetsuo Handa wrote:
> Yury Norov wrote:
> > Hi Tetsuo,
> >
> > Thanks for the patch.
> >
> > On Wed, Apr 04, 2018 at 09:21:43PM +0900, Tetsuo Handa wrote:
> > > Yury, are you OK with this patch?
> > >
> > >
> > > >From
On Thu, Apr 05, 2018 at 12:58:46AM +0900, Tetsuo Handa wrote:
> Yury Norov wrote:
> > Hi Tetsuo,
> >
> > Thanks for the patch.
> >
> > On Wed, Apr 04, 2018 at 09:21:43PM +0900, Tetsuo Handa wrote:
> > > Yury, are you OK with this patch?
> > >
> > >
> > > >From
On Wed, Apr 04, 2018 at 09:38:56AM -0700, Luck, Tony wrote:
> On Wed, Apr 04, 2018 at 09:25:13AM +0200, Peter Zijlstra wrote:
> > Right, I remember being careful with that. Which again brings me to the
> > RANDSTRUCT thing, which will mess that up.
>
> No RANDSTRUCT config options set for my
On Wed, Apr 04, 2018 at 09:38:56AM -0700, Luck, Tony wrote:
> On Wed, Apr 04, 2018 at 09:25:13AM +0200, Peter Zijlstra wrote:
> > Right, I remember being careful with that. Which again brings me to the
> > RANDSTRUCT thing, which will mess that up.
>
> No RANDSTRUCT config options set for my
On Wed, 4 Apr 2018 09:27:10 -0700
Kees Cook wrote:
> On Wed, Apr 4, 2018 at 12:49 AM, Peter Zijlstra wrote:
> > On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote:
> >> If you are concerned about attack surface, I could make it a bit
On Wed, 4 Apr 2018 09:27:10 -0700
Kees Cook wrote:
> On Wed, Apr 4, 2018 at 12:49 AM, Peter Zijlstra wrote:
> > On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote:
> >> If you are concerned about attack surface, I could make it a bit more
> >> difficult to tweak by malicious
On 4/4/2018 6:43 AM, Sagi Grimberg wrote:
IIRC, this might result in nvmet-rdma executing data-transfer even
for failed requests in some error cases. I'm not sure this is the
only case, but have you tested what happens in error cases?
That's why I set transfer_len to zero when we exit this
On 4/4/2018 6:43 AM, Sagi Grimberg wrote:
IIRC, this might result in nvmet-rdma executing data-transfer even
for failed requests in some error cases. I'm not sure this is the
only case, but have you tested what happens in error cases?
That's why I set transfer_len to zero when we exit this
On Wed, Apr 4, 2018 at 11:39 AM, Andy Lutomirski wrote:
> On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote:
>> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote:
>>
>>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote:
>>>
On Wed, Apr 4, 2018 at 11:39 AM, Andy Lutomirski wrote:
> On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote:
>> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote:
>>
>>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote:
>>> > Theodore Y. Ts'o wrote:
>>> >
>>> > > Whoa.
The following changes since commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda:
Linux 4.16 (2018-04-01 14:20:27 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git
tags/riscv-for-linus-4.17-mw0
for you to fetch changes up to
The following changes since commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda:
Linux 4.16 (2018-04-01 14:20:27 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git
tags/riscv-for-linus-4.17-mw0
for you to fetch changes up to
2018-03-29 12:01 GMT+02:00 Greg Kroah-Hartman :
> On Thu, Mar 29, 2018 at 11:47:25AM +0200, Paweł Dembicki wrote:
>> 2018-03-17 12:55 GMT+01:00 Greg Kroah-Hartman :
>>
>> > Where is this patch supposed to go? Is this a stable backport patch,
2018-03-29 12:01 GMT+02:00 Greg Kroah-Hartman :
> On Thu, Mar 29, 2018 at 11:47:25AM +0200, Paweł Dembicki wrote:
>> 2018-03-17 12:55 GMT+01:00 Greg Kroah-Hartman :
>>
>> > Where is this patch supposed to go? Is this a stable backport patch, or
>> > something to go into Linus's tree?
>>
>> I
On Wed, Apr 4, 2018 at 9:39 AM Andy Lutomirski wrote:
> On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote:
> > If you don't have secure boot then an attacker with root can modify your
> > bootloader or kernel, and on next boot lockdown can be silently
On Wed, Apr 4, 2018 at 9:39 AM Andy Lutomirski wrote:
> On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote:
> > If you don't have secure boot then an attacker with root can modify your
> > bootloader or kernel, and on next boot lockdown can be silently
disabled.
> This has been rebutted over
On Wed, Apr 04, 2018 at 09:15:39AM -0700, Davidlohr Bueso wrote:
> On Mon, 02 Apr 2018, Davidlohr Bueso wrote:
>
> > The case for the rt task throttling (which this workload also hits) can be
> > ignored in
> > that the skip_update call is actually bogus and quite the contrary (the
> > request
On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote:
> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote:
>
>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote:
>> > Theodore Y. Ts'o wrote:
>> >
>> > > Whoa. Why doesn't
On Wed, Apr 04, 2018 at 09:15:39AM -0700, Davidlohr Bueso wrote:
> On Mon, 02 Apr 2018, Davidlohr Bueso wrote:
>
> > The case for the rt task throttling (which this workload also hits) can be
> > ignored in
> > that the skip_update call is actually bogus and quite the contrary (the
> > request
On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote:
> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote:
>
>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote:
>> > Theodore Y. Ts'o wrote:
>> >
>> > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why
>> > >
On Wed, Apr 04, 2018 at 09:25:13AM +0200, Peter Zijlstra wrote:
> Right, I remember being careful with that. Which again brings me to the
> RANDSTRUCT thing, which will mess that up.
No RANDSTRUCT config options set for my build.
> Does the below cure things? It makes absolutely no difference
On Wed, Apr 04, 2018 at 09:25:13AM +0200, Peter Zijlstra wrote:
> Right, I remember being careful with that. Which again brings me to the
> RANDSTRUCT thing, which will mess that up.
No RANDSTRUCT config options set for my build.
> Does the below cure things? It makes absolutely no difference
On Wed, Apr 4, 2018 at 9:17 AM, David Howells wrote:
> Andy Lutomirski wrote:
>
>> Since this thread has devolved horribly, I'm going to propose a solution.
>>
>> 1. Split the "lockdown" state into three levels: (please don't
>> bikeshed about the names
On Wed, Apr 4, 2018 at 9:17 AM, David Howells wrote:
> Andy Lutomirski wrote:
>
>> Since this thread has devolved horribly, I'm going to propose a solution.
>>
>> 1. Split the "lockdown" state into three levels: (please don't
>> bikeshed about the names right now.)
>>
>> LOCKDOWN_NONE: normal
Our userspace defines READ_ONCE() in a way that clang
doesn't like, as we have an anonymous union in which neither field is
initialized.
WRITE_ONCE() is fine since it initializes the __val field. For
READ_ONCE() we can keep clang and GCC happy with a dummy initialization
of the __c field, so
Our userspace defines READ_ONCE() in a way that clang
doesn't like, as we have an anonymous union in which neither field is
initialized.
WRITE_ONCE() is fine since it initializes the __val field. For
READ_ONCE() we can keep clang and GCC happy with a dummy initialization
of the __c field, so
On 04/04/2018 06:20 AM, Jiri Slaby wrote:
On 01/07/2018, 10:40 PM, Martin Kelly wrote:
From: Martin Kelly
...
--- a/tools/power/acpi/Makefile.config
+++ b/tools/power/acpi/Makefile.config
@@ -56,9 +56,6 @@ INSTALL_SCRIPT = ${INSTALL_PROGRAM}
# to compile vs uClibc,
On 04/04/2018 06:20 AM, Jiri Slaby wrote:
On 01/07/2018, 10:40 PM, Martin Kelly wrote:
From: Martin Kelly
...
--- a/tools/power/acpi/Makefile.config
+++ b/tools/power/acpi/Makefile.config
@@ -56,9 +56,6 @@ INSTALL_SCRIPT = ${INSTALL_PROGRAM}
# to compile vs uClibc, that can be done here as
On Mon, 02 Apr 2018, Davidlohr Bueso wrote:
The case for the rt task throttling (which this workload also hits) can be
ignored in
that the skip_update call is actually bogus and quite the contrary (the request
bits
are removed/reverted).
While at it, how about this trivial patch?
On Mon, 02 Apr 2018, Davidlohr Bueso wrote:
The case for the rt task throttling (which this workload also hits) can be
ignored in
that the skip_update call is actually bogus and quite the contrary (the request
bits
are removed/reverted).
While at it, how about this trivial patch?
701 - 800 of 1860 matches
Mail list logo