Hello Ingo,
Thank you for the review.
On 10/10/2018 02:17 AM, Ingo Molnar wrote:
>
> * Thara Gopinath wrote:
>
>> Thermal governors can respond to an overheat event for a cpu by
>> capping the cpu's maximum possible frequency. This in turn
>> means that the maximum available compute capacity
Hello Ingo,
Thank you for the review.
On 10/10/2018 02:17 AM, Ingo Molnar wrote:
>
> * Thara Gopinath wrote:
>
>> Thermal governors can respond to an overheat event for a cpu by
>> capping the cpu's maximum possible frequency. This in turn
>> means that the maximum available compute capacity
Hello,
On Wed, Oct 10, 2018 at 08:34:06AM -0700, Alexander Duyck wrote:
> >Maybe we wanna round-robin within the node?
>
> I had thought about it. It adds extra complexity to do it and for
> unbound work queues it doesn't really add anything since it gets
> converted back into a node anyway.
Hello,
On Wed, Oct 10, 2018 at 08:34:06AM -0700, Alexander Duyck wrote:
> >Maybe we wanna round-robin within the node?
>
> I had thought about it. It adds extra complexity to do it and for
> unbound work queues it doesn't really add anything since it gets
> converted back into a node anyway.
On Wed, Oct 10, 2018 at 5:22 PM, Thomas Gleixner wrote:
> On Wed, 10 Oct 2018, syzbot wrote:
>
> Cc+: Miklos
It seems reasonable to ignore arch/.*/mm/physaddr.c as suspected
guilty file in future -- we already ignore everything related to
kmalloc/kfree and this is called from kfree.
I've made
Hi Thara,
I have run it on Exynos5433 mainline.
When it is enabled with step_wise thermal governor,
some of my tests are showing ~30-50% regression (i.e. hackbench),
dhrystone ~10%.
Could you tell me which thermal governor was used in your case?
Please also share the name of that benchmark, i
On Wed, Oct 10, 2018 at 5:22 PM, Thomas Gleixner wrote:
> On Wed, 10 Oct 2018, syzbot wrote:
>
> Cc+: Miklos
It seems reasonable to ignore arch/.*/mm/physaddr.c as suspected
guilty file in future -- we already ignore everything related to
kmalloc/kfree and this is called from kfree.
I've made
Hi Thara,
I have run it on Exynos5433 mainline.
When it is enabled with step_wise thermal governor,
some of my tests are showing ~30-50% regression (i.e. hackbench),
dhrystone ~10%.
Could you tell me which thermal governor was used in your case?
Please also share the name of that benchmark, i
On 10/9/2018 5:00 PM, Brendan Higgins wrote:
Reviewed-by: Brendan Higgins
Thanks for putting all the work in to do it this way!
Thanks a lot for your review, Brendan!
On 10/9/2018 5:00 PM, Brendan Higgins wrote:
Reviewed-by: Brendan Higgins
Thanks for putting all the work in to do it this way!
Thanks a lot for your review, Brendan!
On 10/9/2018 5:00 PM, Brendan Higgins wrote:
Reviewed-by: Brendan Higgins
Thank you!
On Wed, Oct 10, 2018 at 5:32 PM Paul Moore wrote:
> On Tue, Oct 9, 2018 at 9:36 AM Jann Horn wrote:
> > +cc selinux people explicitly, since they probably have opinions on this
>
> I just spent about twenty minutes working my way through this thread,
> and digging through the containers archive
On 10/9/2018 5:00 PM, Brendan Higgins wrote:
Reviewed-by: Brendan Higgins
Thank you!
On Wed, Oct 10, 2018 at 5:32 PM Paul Moore wrote:
> On Tue, Oct 9, 2018 at 9:36 AM Jann Horn wrote:
> > +cc selinux people explicitly, since they probably have opinions on this
>
> I just spent about twenty minutes working my way through this thread,
> and digging through the containers archive
On 10/10/2018 8:30 AM, Tejun Heo wrote:
Hello,
+static int workqueue_select_cpu_near(int node)
+{
...
+ /* Use "random" otherwise know as "first" online CPU of node */
+ cpu = cpumask_any_and(cpumask_of_node(node), cpu_online_mask);
Maybe we wanna round-robin within the
On 10/10/2018 8:30 AM, Tejun Heo wrote:
Hello,
+static int workqueue_select_cpu_near(int node)
+{
...
+ /* Use "random" otherwise know as "first" online CPU of node */
+ cpu = cpumask_any_and(cpumask_of_node(node), cpu_online_mask);
Maybe we wanna round-robin within the
On 10/9/2018 5:08 PM, Brendan Higgins wrote:
Reviewed-by: Brendan Higgins
Thanks for the review, Brendan!
On 10/9/2018 5:08 PM, Brendan Higgins wrote:
Reviewed-by: Brendan Higgins
Thanks for the review, Brendan!
Hello,
> +static int workqueue_select_cpu_near(int node)
> +{
...
> + /* Use "random" otherwise know as "first" online CPU of node */
> + cpu = cpumask_any_and(cpumask_of_node(node), cpu_online_mask);
Maybe we wanna round-robin within the node?
> +bool queue_work_near(int node, struct
Hello,
> +static int workqueue_select_cpu_near(int node)
> +{
...
> + /* Use "random" otherwise know as "first" online CPU of node */
> + cpu = cpumask_any_and(cpumask_of_node(node), cpu_online_mask);
Maybe we wanna round-robin within the node?
> +bool queue_work_near(int node, struct
On Wed, 10 Oct 2018, syzbot wrote:
Cc+: Miklos
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:0854ba5ff5c9 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15e64ea140
> kernel
On Wed, 10 Oct 2018, syzbot wrote:
Cc+: Miklos
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:0854ba5ff5c9 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15e64ea140
> kernel
On Wed, 10 Oct 2018 at 15:48, Quentin Perret wrote:
>
> On Wednesday 10 Oct 2018 at 15:27:57 (+0200), Vincent Guittot wrote:
> > On Wed, 10 Oct 2018 at 15:05, Quentin Perret wrote:
> > >
> > > On Wednesday 10 Oct 2018 at 14:04:40 (+0200), Vincent Guittot wrote:
> > > > This patchset doesn't
On Wed, 10 Oct 2018 at 15:48, Quentin Perret wrote:
>
> On Wednesday 10 Oct 2018 at 15:27:57 (+0200), Vincent Guittot wrote:
> > On Wed, 10 Oct 2018 at 15:05, Quentin Perret wrote:
> > >
> > > On Wednesday 10 Oct 2018 at 14:04:40 (+0200), Vincent Guittot wrote:
> > > > This patchset doesn't
On (10/10/18 14:29), Dmitry Vyukov wrote:
> >> A bit unrelated, but while we are at it:
> >>
> >> I like it when we rate-limit printk-s that lookup the system.
> >> But it seems that default rate-limit values are not always good enough,
> >> DEFAULT_RATELIMIT_INTERVAL / DEFAULT_RATELIMIT_BURST
On (10/10/18 14:29), Dmitry Vyukov wrote:
> >> A bit unrelated, but while we are at it:
> >>
> >> I like it when we rate-limit printk-s that lookup the system.
> >> But it seems that default rate-limit values are not always good enough,
> >> DEFAULT_RATELIMIT_INTERVAL / DEFAULT_RATELIMIT_BURST
This compatible adds the ability for dw spi controller driver to work with
the dw spi controller found on Alpine chips.
The dw spi controller has an auto-deselect of Chip-Select, in case there is
no data inside the Tx FIFO. While working on platforms with Alpine chips,
auto-deselect mode causes
This compatible adds the ability for dw spi controller driver to work with
the dw spi controller found on Alpine chips.
The dw spi controller has an auto-deselect of Chip-Select, in case there is
no data inside the Tx FIFO. While working on platforms with Alpine chips,
auto-deselect mode causes
On Wed, Oct 10, 2018 at 01:03:50AM +, Rik van Riel wrote:
> On Tue, 2018-10-09 at 14:47 -0400, Johannes Weiner wrote:
>
> > These workloads also deal with tens of thousands of open files and
> > use
> > /proc for introspection, which ends up growing the proc_inode_cache
> > to
> > absurdly
Add support for a new devicetree compatible string called
'al,alpine-apb-ssi', which is necessary for the Amazon Alpine spi
controller. 'al,alpine-dw-apb-ssi' is used in the dw spi driver if
specified in the devicetree. Otherwise, fall back to driver default
behavior, i.e. original dw IP hw
On Wed, Oct 10, 2018 at 01:03:50AM +, Rik van Riel wrote:
> On Tue, 2018-10-09 at 14:47 -0400, Johannes Weiner wrote:
>
> > These workloads also deal with tens of thousands of open files and
> > use
> > /proc for introspection, which ends up growing the proc_inode_cache
> > to
> > absurdly
Add support for a new devicetree compatible string called
'al,alpine-apb-ssi', which is necessary for the Amazon Alpine spi
controller. 'al,alpine-dw-apb-ssi' is used in the dw spi driver if
specified in the devicetree. Otherwise, fall back to driver default
behavior, i.e. original dw IP hw
There is a potential execution path in which variable *ret* is checked
in an IF statement, and then its value is used to report an error at
line 659 without being properly initialized previously:
659 if (ret)
660 dev_err(priv->dev, "Failed to write to 0x%x (%d)\n", reg, ret);
Fix this by
Hello,
syzbot found the following crash on:
HEAD commit:0854ba5ff5c9 Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15e64ea140
kernel config: https://syzkaller.appspot.com/x/.config?x=88e9a8a39dc0be2d
There is a potential execution path in which variable *ret* is checked
in an IF statement, and then its value is used to report an error at
line 659 without being properly initialized previously:
659 if (ret)
660 dev_err(priv->dev, "Failed to write to 0x%x (%d)\n", reg, ret);
Fix this by
Hello,
syzbot found the following crash on:
HEAD commit:0854ba5ff5c9 Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15e64ea140
kernel config: https://syzkaller.appspot.com/x/.config?x=88e9a8a39dc0be2d
From: Michal Hocko
syzbot has noticed that it can trigger RCU stalls from the memcg oom
path:
RIP: 0010:dump_stack+0x358/0x3ab lib/dump_stack.c:118
Code: 74 0c 48 c7 c7 f0 f5 31 89 e8 9f 0e 0e fa 48 83 3d 07 15 7d 01 00 0f
84 63 fe ff ff e8 1c 89 c9 f9 48 8b bd 70 ff ff ff 57 9d <0f> 1f 44 00 00
From: Michal Hocko
syzbot has noticed that it can trigger RCU stalls from the memcg oom
path:
RIP: 0010:dump_stack+0x358/0x3ab lib/dump_stack.c:118
Code: 74 0c 48 c7 c7 f0 f5 31 89 e8 9f 0e 0e fa 48 83 3d 07 15 7d 01 00 0f
84 63 fe ff ff e8 1c 89 c9 f9 48 8b bd 70 ff ff ff 57 9d <0f> 1f 44 00 00
On Tue, Oct 09, 2018 at 03:08:45PM -0700, Andrew Morton wrote:
> On Tue, 9 Oct 2018 14:47:32 -0400 Johannes Weiner wrote:
>
> > --- a/mm/workingset.c
> > +++ b/mm/workingset.c
> > @@ -378,11 +378,17 @@ void workingset_update_node(struct xa_node *node)
> > * as node->private_list is
On Tue, Oct 09, 2018 at 03:08:45PM -0700, Andrew Morton wrote:
> On Tue, 9 Oct 2018 14:47:32 -0400 Johannes Weiner wrote:
>
> > --- a/mm/workingset.c
> > +++ b/mm/workingset.c
> > @@ -378,11 +378,17 @@ void workingset_update_node(struct xa_node *node)
> > * as node->private_list is
On Wed, Oct 03, 2018 at 04:38:19PM +0200, Ulf Hansson wrote:
> From: Lina Iyer
>
> Currently CPU's idle states are represented in a flattened model, via the
> "cpu-idle-states" binding from within the CPU's device nodes.
>
> Support the hierarchical layout during parsing and validating of the
On Wed, Oct 03, 2018 at 04:38:19PM +0200, Ulf Hansson wrote:
> From: Lina Iyer
>
> Currently CPU's idle states are represented in a flattened model, via the
> "cpu-idle-states" binding from within the CPU's device nodes.
>
> Support the hierarchical layout during parsing and validating of the
On Wed, Oct 03, 2018 at 04:38:17PM +0200, Ulf Hansson wrote:
> From: Lina Iyer
>
> Update DT bindings to represent hierarchical CPU and CPU PM domain idle
> states for PSCI. Also update the PSCI examples to clearly show how
> flattened and hierarchical idle states can be represented in DT.
>
>
On Wed, Oct 03, 2018 at 04:38:18PM +0200, Ulf Hansson wrote:
> The CPU's idle state nodes are currently parsed at the common cpuidle DT
> library, but also when initializing back-end data for the arch specific CPU
> operations, as in the PSCI driver case.
>
> To avoid open-coding, let's introduce
On Wed, Oct 03, 2018 at 04:38:17PM +0200, Ulf Hansson wrote:
> From: Lina Iyer
>
> Update DT bindings to represent hierarchical CPU and CPU PM domain idle
> states for PSCI. Also update the PSCI examples to clearly show how
> flattened and hierarchical idle states can be represented in DT.
>
>
On Wed, Oct 03, 2018 at 04:38:18PM +0200, Ulf Hansson wrote:
> The CPU's idle state nodes are currently parsed at the common cpuidle DT
> library, but also when initializing back-end data for the arch specific CPU
> operations, as in the PSCI driver case.
>
> To avoid open-coding, let's introduce
On Wed, Oct 10, 2018 at 10:39:59AM -0400, Sasha Levin wrote:
> On Wed, Oct 10, 2018 at 02:45:09PM +0200, Greg KH wrote:
> > On Wed, Oct 10, 2018 at 02:12:01PM +0200, Linus Walleij wrote:
> > > On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
> > > wrote:
> > > > On Wed, Oct 10, 2018 at
On Wed, Oct 10, 2018 at 10:39:59AM -0400, Sasha Levin wrote:
> On Wed, Oct 10, 2018 at 02:45:09PM +0200, Greg KH wrote:
> > On Wed, Oct 10, 2018 at 02:12:01PM +0200, Linus Walleij wrote:
> > > On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
> > > wrote:
> > > > On Wed, Oct 10, 2018 at
On Wed, Oct 03, 2018 at 11:06:45AM -0700, Saravana Kannan wrote:
>
>
> On 10/03/2018 02:33 AM, Sudeep Holla wrote:
> > On Tue, Oct 02, 2018 at 11:56:56AM -0700, Saravana Kannan wrote:
> > > On 10/02/2018 04:17 AM, Sudeep Holla wrote:
> > [...]
> >
> > > > Yes, I do understand I have made the
On Wed, Oct 10, 2018 at 9:09 PM Russell King - ARM Linux
wrote:
>
> On Wed, Oct 10, 2018 at 08:07:52PM +0900, Masahiro Yamada wrote:
> > Hi,
> >
> >
> > I see a bunch of vendor (or SoC) names in
> > Documentation/device/bindings/arm/
> >
> > ./Documentation/devicetree/bindings/arm/altera
> >
On Wed, Oct 03, 2018 at 11:06:45AM -0700, Saravana Kannan wrote:
>
>
> On 10/03/2018 02:33 AM, Sudeep Holla wrote:
> > On Tue, Oct 02, 2018 at 11:56:56AM -0700, Saravana Kannan wrote:
> > > On 10/02/2018 04:17 AM, Sudeep Holla wrote:
> > [...]
> >
> > > > Yes, I do understand I have made the
On Wed, Oct 10, 2018 at 9:09 PM Russell King - ARM Linux
wrote:
>
> On Wed, Oct 10, 2018 at 08:07:52PM +0900, Masahiro Yamada wrote:
> > Hi,
> >
> >
> > I see a bunch of vendor (or SoC) names in
> > Documentation/device/bindings/arm/
> >
> > ./Documentation/devicetree/bindings/arm/altera
> >
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or
On Fri, Oct 05, 2018 at 06:24:42PM +0200, Richard Weinberger wrote:
Sasha,
Am Freitag, 5. Oktober 2018, 18:17:50 CEST schrieb Sasha Levin:
From: Richard Weinberger
[ Upstream commit 37f31b6ca4311b94d985fb398a72e5399ad57925 ]
The requested device name can be NULL or an empty string.
Check
On Fri, Oct 05, 2018 at 06:24:42PM +0200, Richard Weinberger wrote:
Sasha,
Am Freitag, 5. Oktober 2018, 18:17:50 CEST schrieb Sasha Levin:
From: Richard Weinberger
[ Upstream commit 37f31b6ca4311b94d985fb398a72e5399ad57925 ]
The requested device name can be NULL or an empty string.
Check
Hi Charles,
> I don't believe this would fully address the issue since if you
> initialise ret to -1 you will still drop into the if statement
> and you will use the reg variable which should also be
> uninitialised on that code path.
>
> Feels like initialising to 0 would probably be better
On Wed, Oct 10, 2018 at 01:41:32PM +0200, Paul Kocialkowski wrote:
> This adds support for the 3.5" LCD panel from Lemaker, sold for use with
> BananaPi boards. It comes with a 24-bit RGB888 parallel interface and
> requires an active-low DE signal
>
> Signed-off-by: Paul Kocialkowski
> ---
>
Hi Charles,
> I don't believe this would fully address the issue since if you
> initialise ret to -1 you will still drop into the if statement
> and you will use the reg variable which should also be
> uninitialised on that code path.
>
> Feels like initialising to 0 would probably be better
On Wed, Oct 10, 2018 at 01:41:32PM +0200, Paul Kocialkowski wrote:
> This adds support for the 3.5" LCD panel from Lemaker, sold for use with
> BananaPi boards. It comes with a 24-bit RGB888 parallel interface and
> requires an active-low DE signal
>
> Signed-off-by: Paul Kocialkowski
> ---
>
From: Shefali Jain
Add the clocks supported in global clock controller which clock the
peripherals like BLSPs, SDCC, USB, MDSS etc. Register all the clocks
to the clock framework for the clients to be able to request for them.
Signed-off-by: Shefali Jain
Signed-off-by: Taniya Das
From: Shefali Jain
Add the clocks supported in global clock controller which clock the
peripherals like BLSPs, SDCC, USB, MDSS etc. Register all the clocks
to the clock framework for the clients to be able to request for them.
Signed-off-by: Shefali Jain
Signed-off-by: Taniya Das
Add the clock driver for QCS404 SoC. This needs to export
clk_alpha_pll_configure() so first patch does that
Changes in v2:
- Fix comments provided by Stephen & Taniya
Bjorn Andersson (1):
clk: qcom: Export clk_alpha_pll_configure()
Shefali Jain (1):
clk: qcom: gcc: Add global clock
The patch
spi: fsl-lpspi: Prevent FIFO under/overrun by default
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
Add the clock driver for QCS404 SoC. This needs to export
clk_alpha_pll_configure() so first patch does that
Changes in v2:
- Fix comments provided by Stephen & Taniya
Bjorn Andersson (1):
clk: qcom: Export clk_alpha_pll_configure()
Shefali Jain (1):
clk: qcom: gcc: Add global clock
The patch
spi: fsl-lpspi: Prevent FIFO under/overrun by default
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
From: Bjorn Andersson
This is used by the QCS404 GCC driver, export it to allow that driver to
be compiled as a module..
Signed-off-by: Bjorn Andersson
Signed-off-by: Vinod Koul
---
drivers/clk/qcom/clk-alpha-pll.c | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Bjorn Andersson
This is used by the QCS404 GCC driver, export it to allow that driver to
be compiled as a module..
Signed-off-by: Bjorn Andersson
Signed-off-by: Vinod Koul
---
drivers/clk/qcom/clk-alpha-pll.c | 1 +
1 file changed, 1 insertion(+)
diff --git
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or
Hi,
On Mon, Oct 08, 2018 at 06:20:42PM +0300, Aleksandr Aleksandrov wrote:
> Emlid Neutis N5 is a SoM based on Allwinner H5, has a WiFi & BT
> module, DDR3 RAM and eMMC.
>
> - add neutis n5 dtsi file for SoM needs
> - add neutis devboard dts file
> - add neutis devboard target to dtb makefile
>
Hi,
On Mon, Oct 08, 2018 at 06:20:42PM +0300, Aleksandr Aleksandrov wrote:
> Emlid Neutis N5 is a SoM based on Allwinner H5, has a WiFi & BT
> module, DDR3 RAM and eMMC.
>
> - add neutis n5 dtsi file for SoM needs
> - add neutis devboard dts file
> - add neutis devboard target to dtb makefile
>
On Wed, Oct 10, 2018 at 12:03 AM, Miguel Ojeda
wrote:
> On Wed, Oct 10, 2018 at 8:12 AM Joel Stanley wrote:
>>
>> On Thu, 27 Sep 2018 at 05:07, Kees Cook wrote:
>> >
>> > Yeah, that's what I'd linked to in the patchwork URL. Andrew, can you take
>> > this?
>>
>> clang built -next is blowing up
Dmitry Vyukov wrote on Wed, Oct 10, 2018:
> > Back to the current patch, since as I said I am not confident this is a
> > good enough fix for the current bug, will I get notified if the bug
> > happens again once the patch hits linux-next with the Reported-by tag ?
> > (I don't have the setup
On Wed, Oct 10, 2018 at 12:03 AM, Miguel Ojeda
wrote:
> On Wed, Oct 10, 2018 at 8:12 AM Joel Stanley wrote:
>>
>> On Thu, 27 Sep 2018 at 05:07, Kees Cook wrote:
>> >
>> > Yeah, that's what I'd linked to in the patchwork URL. Andrew, can you take
>> > this?
>>
>> clang built -next is blowing up
Dmitry Vyukov wrote on Wed, Oct 10, 2018:
> > Back to the current patch, since as I said I am not confident this is a
> > good enough fix for the current bug, will I get notified if the bug
> > happens again once the patch hits linux-next with the Reported-by tag ?
> > (I don't have the setup
On 10/10/18, Borislav Petkov wrote:
> On Wed, Oct 10, 2018 at 04:32:45PM +0200, Arnd Bergmann wrote:
>> We get a link failure when calling copy_oldmem_page_encrypted()
>> when the compiler fails to do constant-propagation of the
>> sme_active() result into read_from_oldmem:
>>
>>
On 10/10/18, Borislav Petkov wrote:
> On Wed, Oct 10, 2018 at 04:32:45PM +0200, Arnd Bergmann wrote:
>> We get a link failure when calling copy_oldmem_page_encrypted()
>> when the compiler fails to do constant-propagation of the
>> sme_active() result into read_from_oldmem:
>>
>>
Hi Arnd,
On Wed, Oct 10, 2018 at 4:01 PM Arnd Bergmann wrote:
> On 10/10/18, Geert Uytterhoeven wrote:
> > Since commit 01973a01f9ec34b7 ("eeprom: at25: remove nvmem regmap
> > dependency") changed the type of "off" from "loff_t" to "unsigned int",
> > there is no longer a need to cast it to
Hi Arnd,
On Wed, Oct 10, 2018 at 4:01 PM Arnd Bergmann wrote:
> On 10/10/18, Geert Uytterhoeven wrote:
> > Since commit 01973a01f9ec34b7 ("eeprom: at25: remove nvmem regmap
> > dependency") changed the type of "off" from "loff_t" to "unsigned int",
> > there is no longer a need to cast it to
Dmitry Vyukov wrote on Wed, Oct 10, 2018:
> How can they be faked?
> If we could create a private rdma/virtio stub instance per test
> process, then we could I think easily use that instance for 9p. But is
> it possible?
"RDMA" itself can be faked pretty easily nowadays, there's a "rxe"
driver
Dmitry Vyukov wrote on Wed, Oct 10, 2018:
> How can they be faked?
> If we could create a private rdma/virtio stub instance per test
> process, then we could I think easily use that instance for 9p. But is
> it possible?
"RDMA" itself can be faked pretty easily nowadays, there's a "rxe"
driver
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or
On Wed, Oct 10, 2018 at 04:32:45PM +0200, Arnd Bergmann wrote:
> We get a link failure when calling copy_oldmem_page_encrypted()
> when the compiler fails to do constant-propagation of the
> sme_active() result into read_from_oldmem:
>
> fs/proc/vmcore.o: In function `read_from_oldmem.part.0':
>
The patch
ASoC: max98988: add I2C dependency
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
On Wed, Oct 10, 2018 at 04:32:45PM +0200, Arnd Bergmann wrote:
> We get a link failure when calling copy_oldmem_page_encrypted()
> when the compiler fails to do constant-propagation of the
> sme_active() result into read_from_oldmem:
>
> fs/proc/vmcore.o: In function `read_from_oldmem.part.0':
>
The patch
ASoC: max98988: add I2C dependency
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
The patch
regulator: stpmic1: Return REGULATOR_MODE_INVALID for invalid mode
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
regulator: stpmic1: Return REGULATOR_MODE_INVALID for invalid mode
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
On Wed, Oct 10, 2018 at 02:45:09PM +0200, Greg KH wrote:
On Wed, Oct 10, 2018 at 02:12:01PM +0200, Linus Walleij wrote:
On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
wrote:
> On Wed, Oct 10, 2018 at 09:12:58AM +0200, Linus Walleij wrote:
> > On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
On Wed, Oct 10, 2018 at 02:45:09PM +0200, Greg KH wrote:
On Wed, Oct 10, 2018 at 02:12:01PM +0200, Linus Walleij wrote:
On Wed, Oct 10, 2018 at 9:53 AM Nathan Chancellor
wrote:
> On Wed, Oct 10, 2018 at 09:12:58AM +0200, Linus Walleij wrote:
> > On Tue, Oct 9, 2018 at 8:33 AM Nathan Chancellor
On Wed, Oct 10, 2018 at 04:13:53PM +0200, Gustavo A. R. Silva wrote:
> There is a potential execution path in which variable *ret* is checked
> in an IF statement, and then its value is used to report an error at
> line 659 without being properly initialized previously:
>
> 659 if (ret)
> 660
On Wed, Oct 10, 2018 at 04:13:53PM +0200, Gustavo A. R. Silva wrote:
> There is a potential execution path in which variable *ret* is checked
> in an IF statement, and then its value is used to report an error at
> line 659 without being properly initialized previously:
>
> 659 if (ret)
> 660
We get a link failure when calling copy_oldmem_page_encrypted()
when the compiler fails to do constant-propagation of the
sme_active() result into read_from_oldmem:
fs/proc/vmcore.o: In function `read_from_oldmem.part.0':
vmcore.c:(.text+0xb7): undefined reference to `copy_oldmem_page_encrypted'
We get a link failure when calling copy_oldmem_page_encrypted()
when the compiler fails to do constant-propagation of the
sme_active() result into read_from_oldmem:
fs/proc/vmcore.o: In function `read_from_oldmem.part.0':
vmcore.c:(.text+0xb7): undefined reference to `copy_oldmem_page_encrypted'
Thomas,
On 10/10/2018 09:16 AM, Thomas Gleixner wrote:
> Babu,
>
> On Wed, 10 Oct 2018, Moger, Babu wrote:
>> On 10/09/2018 05:01 PM, Reinette Chatre wrote:
>>> As far as all the code you touch is concerned it may be easier and cause
>>> less confusion for now to just follow the current naming
Thomas,
On 10/10/2018 09:16 AM, Thomas Gleixner wrote:
> Babu,
>
> On Wed, 10 Oct 2018, Moger, Babu wrote:
>> On 10/09/2018 05:01 PM, Reinette Chatre wrote:
>>> As far as all the code you touch is concerned it may be easier and cause
>>> less confusion for now to just follow the current naming
On Mon, Oct 08, 2018 at 12:20:26PM -0700, Dmitry Torokhov wrote:
Hi Michael,
On Mon, Oct 8, 2018 at 12:09 PM Michael Schmitz wrote:
Dmitry,
someone on debian-68k reported the bug, which (to me) indicates that the
code is not just used by me.
Whether or not a functioning Capslock is
On Mon, Oct 08, 2018 at 12:20:26PM -0700, Dmitry Torokhov wrote:
Hi Michael,
On Mon, Oct 8, 2018 at 12:09 PM Michael Schmitz wrote:
Dmitry,
someone on debian-68k reported the bug, which (to me) indicates that the
code is not just used by me.
Whether or not a functioning Capslock is
801 - 900 of 1504 matches
Mail list logo
