>> Still, isn't there subsystem-level default that all events are disabled
>> by default? If such, then current hi8435 state breaks subsystem-level
>> rules, which is a [userspace-visible] bug. I'm not sure how far should
>> we go in bug compatibility.
>
> It is indeed the subsystem default (as
>> Still, isn't there subsystem-level default that all events are disabled
>> by default? If such, then current hi8435 state breaks subsystem-level
>> rules, which is a [userspace-visible] bug. I'm not sure how far should
>> we go in bug compatibility.
>
> It is indeed the subsystem default (as
On Mon, May 29, 2017 at 7:40 AM, Hyunchul Lee wrote:
>
> and I missed the following case.
>
> in some embedded systems, clean-up for shutdown should be fast.
> during this clean-up, freeze file system to guarantee integrity.
> umount with MNT_DETACH is not suitable because of
Hi Linus,
After merging the gpio tree, today's linux-next build (arm
orion5x_defconfig) failed like this:
drivers/gpio/gpio-mvebu.c:1062: undefined reference to
`__devm_regmap_init_mmio_clk'
drivers/gpio/gpio-mvebu.c:1078: undefined reference to
`__devm_regmap_init_mmio_clk'
Caused by commit
On Mon, May 29, 2017 at 7:40 AM, Hyunchul Lee wrote:
>
> and I missed the following case.
>
> in some embedded systems, clean-up for shutdown should be fast.
> during this clean-up, freeze file system to guarantee integrity.
> umount with MNT_DETACH is not suitable because of not killing tasks.
>
Hi Linus,
After merging the gpio tree, today's linux-next build (arm
orion5x_defconfig) failed like this:
drivers/gpio/gpio-mvebu.c:1062: undefined reference to
`__devm_regmap_init_mmio_clk'
drivers/gpio/gpio-mvebu.c:1078: undefined reference to
`__devm_regmap_init_mmio_clk'
Caused by commit
Reza Arbab writes:
> On Fri, May 26, 2017 at 01:46:58PM +1000, Michael Ellerman wrote:
>>Reza Arbab writes:
>>
>>> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
The commit message for 3af229f2071f says:
In
Reza Arbab writes:
> On Fri, May 26, 2017 at 01:46:58PM +1000, Michael Ellerman wrote:
>>Reza Arbab writes:
>>
>>> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
The commit message for 3af229f2071f says:
In practice, we never see a system with 256 NUMA nodes,
Currently applications can explicitly enable or disable THP for a memory
region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of
these advises is used, the region will always have
VM_HUGEPAGE/VM_NOHUGEPAGE flag set in vma->vm_flags.
The MADV_RESET_HUGEPAGE resets both these flags
Currently applications can explicitly enable or disable THP for a memory
region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of
these advises is used, the region will always have
VM_HUGEPAGE/VM_NOHUGEPAGE flag set in vma->vm_flags.
The MADV_RESET_HUGEPAGE resets both these flags
From: Eric Biggers
synaptics_query_hardware() was being passed a
'struct synaptics_device_info' in uninitialized stack memory, then not
always initializing all fields. This caused garbage to show up in
certain fields, making the touchpad unusable.
Fix by zeroing the device
From: Eric Biggers
synaptics_query_hardware() was being passed a
'struct synaptics_device_info' in uninitialized stack memory, then not
always initializing all fields. This caused garbage to show up in
certain fields, making the touchpad unusable.
Fix by zeroing the device info, so all fields
Rob Landley writes:
> On 05/25/2017 04:24 PM, Stephen Rothwell wrote:
>> Hi Michael,
>>
>> On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman
>> wrote:
>>>
>>> It'll be:
>>>
>>> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT")
>>
Rob Landley writes:
> On 05/25/2017 04:24 PM, Stephen Rothwell wrote:
>> Hi Michael,
>>
>> On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman
>> wrote:
>>>
>>> It'll be:
>>>
>>> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT")
>>
>> And Andrew has asked me to drop that
Hi Rafael,
On 5/28/2017 12:48 AM, Rafael J. Wysocki wrote:
> On Saturday, May 27, 2017 07:17:42 PM Sricharan R wrote:
>> While deferring the probe of IOMMU masters, xlate and
>> add_device callbacks called from iort_iommu_configure
>> can pass back error values like -ENODEV, which means
>> the
Hi Rafael,
On 5/28/2017 12:48 AM, Rafael J. Wysocki wrote:
> On Saturday, May 27, 2017 07:17:42 PM Sricharan R wrote:
>> While deferring the probe of IOMMU masters, xlate and
>> add_device callbacks called from iort_iommu_configure
>> can pass back error values like -ENODEV, which means
>> the
Oops, sent last one without patch on accident. Attached this time.
This has been happening for me since 4.10
dquot_writeback_dquots expects a lock to be held on super_block->s_umount ,
and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not
obtain such a lock.
Thus, the following
Oops, sent last one without patch on accident. Attached this time.
This has been happening for me since 4.10
dquot_writeback_dquots expects a lock to be held on super_block->s_umount ,
and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not
obtain such a lock.
Thus, the following
This has been happening for me since 4.10
dquot_writeback_dquots expects a lock to be held on super_block->s_umount ,
and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not
obtain such a lock.
Thus, the following warning is generated:
[Sun May 28 04:58:06 2017] [ cut
This has been happening for me since 4.10
dquot_writeback_dquots expects a lock to be held on super_block->s_umount ,
and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not
obtain such a lock.
Thus, the following warning is generated:
[Sun May 28 04:58:06 2017] [ cut
OCC provides historical minimum and maximum value for the sensor
readings. This patch exports them as highest and lowest attributes
for the inband sensors copied by OCC to main memory.
Signed-off-by: Shilpasri G Bhat
---
Changes from V4:
- Got rid of 'len'
OCC provides historical minimum and maximum value for the sensor
readings. This patch exports them as highest and lowest attributes
for the inband sensors copied by OCC to main memory.
Signed-off-by: Shilpasri G Bhat
---
Changes from V4:
- Got rid of 'len' variable in populate_attr_groups
and I missed the following case.
in some embedded systems, clean-up for shutdown should be fast.
during this clean-up, freeze file system to guarantee integrity.
umount with MNT_DETACH is not suitable because of not killing tasks.
On Mon, May 29, 2017 at 10:18:34AM +0900, Hyunchul Lee wrote:
>
and I missed the following case.
in some embedded systems, clean-up for shutdown should be fast.
during this clean-up, freeze file system to guarantee integrity.
umount with MNT_DETACH is not suitable because of not killing tasks.
On Mon, May 29, 2017 at 10:18:34AM +0900, Hyunchul Lee wrote:
>
Signed-off-by: Martin Schiller
---
drivers/pinctrl/pinctrl-xway.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-xway.c b/drivers/pinctrl/pinctrl-xway.c
index d4167e2..f9e98a7 100644
--- a/drivers/pinctrl/pinctrl-xway.c
+++
Signed-off-by: Martin Schiller
---
drivers/pinctrl/pinctrl-xway.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-xway.c b/drivers/pinctrl/pinctrl-xway.c
index d4167e2..f9e98a7 100644
--- a/drivers/pinctrl/pinctrl-xway.c
+++
Hi Gustavo,
> desc = dmaengine_prep_slave_sg(dma->ch, sgt->sgl, sgt->nents,
> dma->direction, DMA_PREP_INTERRUPT);
>
> + if (!desc) {
> + dev_err(>master->dev,
> + "%s:dmaengine_prep_slave_sg Failed\n", __func__);
>
Hi Gustavo,
> desc = dmaengine_prep_slave_sg(dma->ch, sgt->sgl, sgt->nents,
> dma->direction, DMA_PREP_INTERRUPT);
>
> + if (!desc) {
> + dev_err(>master->dev,
> + "%s:dmaengine_prep_slave_sg Failed\n", __func__);
>
Hi all,
Changes since 20170526:
Non-merge commits (relative to Linus' tree): 2862
3154 files changed, 118750 insertions(+), 64872 deletions(-)
I have created today's linux-next tree at
Hi all,
Changes since 20170526:
Non-merge commits (relative to Linus' tree): 2862
3154 files changed, 118750 insertions(+), 64872 deletions(-)
I have created today's linux-next tree at
On 05/27/2017 06:53 AM, David Woods wrote:
> Using the device_property interfaces allows the dw_mmc driver to work
> on platforms which run on either device tree or ACPI.
>
> Signed-off-by: David Woods
> Reviewed-by: Chris Metcalf
> Cc:
On 05/27/2017 06:53 AM, David Woods wrote:
> Using the device_property interfaces allows the dw_mmc driver to work
> on platforms which run on either device tree or ACPI.
>
> Signed-off-by: David Woods
> Reviewed-by: Chris Metcalf
> Cc: sta...@vger.linux.org
Acked-by: Jaehoon Chung
Best
Any further review comments on this patch series?
can it go in 4.13?
On Tue, May 16, 2017 at 2:03 PM, Ganapatrao Kulkarni
wrote:
> Extending json/jevent framework for parsing arm64 event files.
> Adding jevents for ThunderX2 implementation defined PMU events.
>
>
Any further review comments on this patch series?
can it go in 4.13?
On Tue, May 16, 2017 at 2:03 PM, Ganapatrao Kulkarni
wrote:
> Extending json/jevent framework for parsing arm64 event files.
> Adding jevents for ThunderX2 implementation defined PMU events.
>
> v3:
>- Addressed comments
The help info of `make -C=1` is little confusing, make it clear.
Signed-off-by: Cao jin
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index efa267a..b34a34d 100644
--- a/Makefile
+++ b/Makefile
@@ -1417,7 +1417,7
The help info of `make -C=1` is little confusing, make it clear.
Signed-off-by: Cao jin
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index efa267a..b34a34d 100644
--- a/Makefile
+++ b/Makefile
@@ -1417,7 +1417,7 @@ help:
@echo '
Hi Mark, Will,
can you please review this patchset?
On Wed, May 17, 2017 at 12:30 PM, Ganapatrao Kulkarni
wrote:
> This adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices.
> The SoC has PMU support in its L3 cache controller (L3C) and in the
> DDR4 Memory
Hi Mark, Will,
can you please review this patchset?
On Wed, May 17, 2017 at 12:30 PM, Ganapatrao Kulkarni
wrote:
> This adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices.
> The SoC has PMU support in its L3 cache controller (L3C) and in the
> DDR4 Memory Controller (DMC).
>
> Ganapatrao
Thanks for catching this.
BR,
Souvik
> -Original Message-
> From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver-
> x86-ow...@vger.kernel.org] On Behalf Of priyalee.kushw...@intel.com
> Sent: Saturday, May 27, 2017 8:48 PM
> To: dvh...@infradead.org; Chakravarty,
Thanks for catching this.
BR,
Souvik
> -Original Message-
> From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver-
> x86-ow...@vger.kernel.org] On Behalf Of priyalee.kushw...@intel.com
> Sent: Saturday, May 27, 2017 8:48 PM
> To: dvh...@infradead.org; Chakravarty,
Signed-off-by: Josh Benson
---
drivers/thermal/thermal_hwmon.c | 20 +++-
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index 541af5946203..c4a508a124dc 100644
---
Signed-off-by: Josh Benson
---
drivers/thermal/thermal_hwmon.c | 20 +++-
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index 541af5946203..c4a508a124dc 100644
--- a/drivers/thermal/thermal_hwmon.c
Hi, Richard.
On Mon, May 29, 2017 at 09:43:46AM +0900, Hyunchul Lee wrote:
> On Sat, May 27, 2017 at 01:23:38AM -0700, Christoph Hellwig wrote:
> > > +static int ubifs_freeze_super(struct super_block *sb)
> > > +{
> > > + struct ubifs_info *c = sb->s_fs_info;
> > > + int err;
> > > +
> > > +
Hi, Richard.
On Mon, May 29, 2017 at 09:43:46AM +0900, Hyunchul Lee wrote:
> On Sat, May 27, 2017 at 01:23:38AM -0700, Christoph Hellwig wrote:
> > > +static int ubifs_freeze_super(struct super_block *sb)
> > > +{
> > > + struct ubifs_info *c = sb->s_fs_info;
> > > + int err;
> > > +
> > > +
Current busy-wait loops are implemented by repeatedly calling cpu_relax()
to give an arch option for a low-latency option to improve power and/or
SMT resource contention.
This poses some difficulties for powerpc, which has SMT priority setting
instructions (priorities determine how ifetch cycles
Current busy-wait loops are implemented by repeatedly calling cpu_relax()
to give an arch option for a low-latency option to improve power and/or
SMT resource contention.
This poses some difficulties for powerpc, which has SMT priority setting
instructions (priorities determine how ifetch cycles
Guenter Roeck writes:
> On 05/26/2017 06:22 PM, Murilo Opsfelder Araujo wrote:
>> drivers/watchdog/wdrtas.c uses symbols defined in arch/powerpc/kernel/rtas.c,
>> which are exported iff CONFIG_PPC_RTAS is selected. Building wdrtas.c without
>> setting CONFIG_PPC_RTAS throws
Guenter Roeck writes:
> On 05/26/2017 06:22 PM, Murilo Opsfelder Araujo wrote:
>> drivers/watchdog/wdrtas.c uses symbols defined in arch/powerpc/kernel/rtas.c,
>> which are exported iff CONFIG_PPC_RTAS is selected. Building wdrtas.c without
>> setting CONFIG_PPC_RTAS throws the following errors:
hi Linux
http://www.retirodecasais.novidadedevida.com.br/poll_success.php?rule=266d8zbvkqkdm2
Yours
Dennis
hi Linux
http://www.retirodecasais.novidadedevida.com.br/poll_success.php?rule=266d8zbvkqkdm2
Yours
Dennis
Hi, Richard.
On Fri, May 26, 2017 at 11:52:42AM +0200, Richard Weinberger wrote:
> Hyunchul,
>
> Am 26.05.2017 um 01:30 schrieb Hyunchul Lee:
> > From: Hyunchul Lee
> >
> > for un/freeze support, implement freeze_super and un/freeze_fs
> > of super_operations.
> >
Hi, Richard.
On Fri, May 26, 2017 at 11:52:42AM +0200, Richard Weinberger wrote:
> Hyunchul,
>
> Am 26.05.2017 um 01:30 schrieb Hyunchul Lee:
> > From: Hyunchul Lee
> >
> > for un/freeze support, implement freeze_super and un/freeze_fs
> > of super_operations.
> > ubifs_freeze_super just calls
__zram_bvec_write has some of duplicated logic for zram meta
data handling of same_page|dedup_page|compressed_page.
This patch aims to clean it up without behavior change.
Cc: Sergey Senozhatsky
Signed-off-by: Minchan Kim
---
__zram_bvec_write has some of duplicated logic for zram meta
data handling of same_page|dedup_page|compressed_page.
This patch aims to clean it up without behavior change.
Cc: Sergey Senozhatsky
Signed-off-by: Minchan Kim
---
drivers/block/zram/zram_drv.c | 70
On Sat, May 27, 2017 at 01:23:38AM -0700, Christoph Hellwig wrote:
> > +static int ubifs_freeze_super(struct super_block *sb)
> > +{
> > + struct ubifs_info *c = sb->s_fs_info;
> > + int err;
> > +
> > + dbg_gen("starting");
> > + /* freeze_super always succeeds if file system is in
On Sat, May 27, 2017 at 01:23:38AM -0700, Christoph Hellwig wrote:
> > +static int ubifs_freeze_super(struct super_block *sb)
> > +{
> > + struct ubifs_info *c = sb->s_fs_info;
> > + int err;
> > +
> > + dbg_gen("starting");
> > + /* freeze_super always succeeds if file system is in
Hi Wolfram
Thankyou for the fixup
On 28/05/17 18:30, Wolfram Sang wrote:
> It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text.
>
> Signed-off-by: Wolfram Sang
Acked-by: Kieran Bingham
Hi Wolfram
Thankyou for the fixup
On 28/05/17 18:30, Wolfram Sang wrote:
> It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text.
>
> Signed-off-by: Wolfram Sang
Acked-by: Kieran Bingham
Mauro,
I'll leave this for you to pick up when you're ready.
Thanks
Kieran
>
Hey, things continue to look good, and rc3 isn't even very big. I'm
hoping there's not another shoe about to drop, but so far this really
feels like a nice calm release cycle, despite the size of the merge
window.
Knock wood.
Anyway, rc3 has a little bit of everything. The biggest single change
Hey, things continue to look good, and rc3 isn't even very big. I'm
hoping there's not another shoe about to drop, but so far this really
feels like a nice calm release cycle, despite the size of the merge
window.
Knock wood.
Anyway, rc3 has a little bit of everything. The biggest single change
On Fri, May 26, 2017 at 10:02:25PM +0100, Piotr Gregor wrote:
> The test for INTx masking via config space command performed
> in pci_intx_mask_supported() should be performed before PCI device
> can be used. This is to avoid reading/writing of PCI_COMMAND_INTX_DISABLE
> register which may collide
On Fri, May 26, 2017 at 10:02:25PM +0100, Piotr Gregor wrote:
> The test for INTx masking via config space command performed
> in pci_intx_mask_supported() should be performed before PCI device
> can be used. This is to avoid reading/writing of PCI_COMMAND_INTX_DISABLE
> register which may collide
On 01/01/2017 02:42 PM, Florian Fainelli wrote:
> Hi all,
>
> This patch series removes dead DSA code in the blackfin board specific
> code. There is no in tree driver for the KSZ8893M, and clearly this
> would not compile anymore.
>
> Preparatory patch to help remove the legacy DSA platform
On 01/01/2017 02:42 PM, Florian Fainelli wrote:
> Hi all,
>
> This patch series removes dead DSA code in the blackfin board specific
> code. There is no in tree driver for the KSZ8893M, and clearly this
> would not compile anymore.
>
> Preparatory patch to help remove the legacy DSA platform
Hi Andrew,
On Fri, 26 May 2017 23:36:00 -0700 Andrew Morton
wrote:
>
> On Fri, 26 May 2017 15:48:51 -0500 Dave Kleikamp
> wrote:
>
> > Andrew,
> >
> > Do you want to pick this up into akpm-current? I could push it through
> > the jfs
Hi Andrew,
On Fri, 26 May 2017 23:36:00 -0700 Andrew Morton
wrote:
>
> On Fri, 26 May 2017 15:48:51 -0500 Dave Kleikamp
> wrote:
>
> > Andrew,
> >
> > Do you want to pick this up into akpm-current? I could push it through
> > the jfs tree, but without the change to write_one_page(), my
On Sun, May 28, 2017 at 11:56 AM, Boris Lukashev
wrote:
> So what about a middle ground where CoW semantics are used to enforce
> the state of these allocations as RO, but provide a strictly
> controlled pathway to read the RO data, copy and modify it, then write
> and
On Sun, May 28, 2017 at 11:56 AM, Boris Lukashev
wrote:
> So what about a middle ground where CoW semantics are used to enforce
> the state of these allocations as RO, but provide a strictly
> controlled pathway to read the RO data, copy and modify it, then write
> and seal into a new allocation.
On Sun, May 28, 2017 at 1:29 PM, Tetsuo Handa
wrote:
> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> registration.") treats "struct security_hook_heads" as an implicit array
> of "struct list_head" so that we can eliminate code for static
On Sun, May 28, 2017 at 1:29 PM, Tetsuo Handa
wrote:
> Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
> registration.") treats "struct security_hook_heads" as an implicit array
> of "struct list_head" so that we can eliminate code for static
> initialization. Although we
Hi Paolo, Hi Jonathan,
On Sun, May 28, 2017 at 4:43 PM, Jonathan Cameron wrote:
> On Sun, 28 May 2017 13:24:38 +0200
> Paolo Cretaro wrote:
>
>> Fix sparse warning: Using plain integer as NULL pointer
>>
>> Signed-off-by: Paolo Cretaro
Hi Paolo, Hi Jonathan,
On Sun, May 28, 2017 at 4:43 PM, Jonathan Cameron wrote:
> On Sun, 28 May 2017 13:24:38 +0200
> Paolo Cretaro wrote:
>
>> Fix sparse warning: Using plain integer as NULL pointer
>>
>> Signed-off-by: Paolo Cretaro
> This looks fine to me, but ideally you should always try
Hi Sean,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.12-rc2 next-20170526]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Sean,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.12-rc2 next-20170526]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
On Wed, May 24, 2017 at 9:01 AM, Vince Weaver wrote:
>
> On Wed, 24 May 2017, Andi Kleen wrote:
>
> > > Right, I did not even consider the rdpmc, but yeah, you will get a count
> > > that
> > > is not relevant to the user visible event. Unless you fake it using the
> >
On Wed, May 24, 2017 at 9:01 AM, Vince Weaver wrote:
>
> On Wed, 24 May 2017, Andi Kleen wrote:
>
> > > Right, I did not even consider the rdpmc, but yeah, you will get a count
> > > that
> > > is not relevant to the user visible event. Unless you fake it using the
> > > time
> > > scaling
Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
registration.") treats "struct security_hook_heads" as an implicit array
of "struct list_head" so that we can eliminate code for static
initialization. Although we haven't encountered compilers which do not
treat
Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon
registration.") treats "struct security_hook_heads" as an implicit array
of "struct list_head" so that we can eliminate code for static
initialization. Although we haven't encountered compilers which do not
treat
From: Borislav Petkov
With CONFIG_DEBUG_PREEMPT enabled, I get:
BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is debug_smp_processor_id
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2+ #2
Call Trace:
dump_stack
From: Borislav Petkov
With CONFIG_DEBUG_PREEMPT enabled, I get:
BUG: using smp_processor_id() in preemptible [] code: swapper/0/1
caller is debug_smp_processor_id
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2+ #2
Call Trace:
dump_stack
check_preemption_disabled
> The code for the special v1p8 / v2p8 gpios is ugly as sin, it operates on
> a global v2p8_gpio value rather then storing info in the gmin_subdev struct,
> as such passing the subdev->dev pointer would be simply wrong. AFAICT the
> v1p8 / v2p8 gpio code is the only caller passing in a NULL
> The code for the special v1p8 / v2p8 gpios is ugly as sin, it operates on
> a global v2p8_gpio value rather then storing info in the gmin_subdev struct,
> as such passing the subdev->dev pointer would be simply wrong. AFAICT the
> v1p8 / v2p8 gpio code is the only caller passing in a NULL
On Mon, 29 May 2017 02:06:41 +0800
Chen Guanqiao wrote:
> Fix "symbol 'xxx' was not declared. Should it be static?" sparse warnings.
>
> Signed-off-by: Chen Guanqiao
> ---
Reviewed-by: Alan Cox
On Mon, 29 May 2017 02:06:41 +0800
Chen Guanqiao wrote:
> Fix "symbol 'xxx' was not declared. Should it be static?" sparse warnings.
>
> Signed-off-by: Chen Guanqiao
> ---
Reviewed-by: Alan Cox
Hi Tejun,
I suspect this is a long-standing bug introduced by all the pool rework
you did at some point, but I don't really know nor can I figure out how
to fix it right now. I guess it could possibly also be a lockdep issue,
or an issue in how it's used, but I definitely know that this used to
Hi Tejun,
I suspect this is a long-standing bug introduced by all the pool rework
you did at some point, but I don't really know nor can I figure out how
to fix it right now. I guess it could possibly also be a lockdep issue,
or an issue in how it's used, but I definitely know that this used to
On Thu 2017-05-25 12:46:04, Bernd Petrovitsch wrote:
> On Thu, 2017-05-25 at 03:35 -0700, Joe Perches wrote:
> > On Wed, 2017-05-24 at 13:18 +0300, Alexey Dobriyan wrote:
> > > Proper fix is to introduce typed allocation macros with the following
> > > signatures:
> > >
> > > T* lmalloc(T, gfp);
On Thu 2017-05-25 12:46:04, Bernd Petrovitsch wrote:
> On Thu, 2017-05-25 at 03:35 -0700, Joe Perches wrote:
> > On Wed, 2017-05-24 at 13:18 +0300, Alexey Dobriyan wrote:
> > > Proper fix is to introduce typed allocation macros with the following
> > > signatures:
> > >
> > > T* lmalloc(T, gfp);
Hi!
> The status reported directly by the battery controller is not always
> reliable and should be corrected based on the current draw information.
>
> This implements such a correction with a dedicated function, called
> when retrieving the supply status.
>
> @@ -1182,6 +1196,8 @@ static int
Hi!
> The status reported directly by the battery controller is not always
> reliable and should be corrected based on the current draw information.
>
> This implements such a correction with a dedicated function, called
> when retrieving the supply status.
>
> @@ -1182,6 +1196,8 @@ static int
One-time sealable memory makes the most sense from a defensive
perspective - red team reads this stuff, the races mentioned will be
implemented as described to win the day, and probably in other
innovative ways. If a gap is left in the implementation, without
explicit coverage by an adjacent
One-time sealable memory makes the most sense from a defensive
perspective - red team reads this stuff, the races mentioned will be
implemented as described to win the day, and probably in other
innovative ways. If a gap is left in the implementation, without
explicit coverage by an adjacent
On Sun, May 28, 2017 at 11:18 AM, Bernhard Held wrote:
> Hi,
>
> this patch breaks the boot of my kernel. The last message is "Booting
> the kernel.".
>
> My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a
> Gigbayte G33-DS3R board (LGA 775). The BIOS is patched
On Sun, May 28, 2017 at 11:18 AM, Bernhard Held wrote:
> Hi,
>
> this patch breaks the boot of my kernel. The last message is "Booting
> the kernel.".
>
> My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a
> Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the
>
Hi,
this patch breaks the boot of my kernel. The last message is "Booting
the kernel.".
My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a
Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the
microcode of the E5450 and recognizes the CPU.
Please find below the dmesg
Hi,
this patch breaks the boot of my kernel. The last message is "Booting
the kernel.".
My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a
Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the
microcode of the E5450 and recognizes the CPU.
Please find below the dmesg
On 28/05/2017 15:59, Linus Walleij wrote:
> On Tue, May 16, 2017 at 9:58 AM, Andrew Jeffery wrote:
>
>> Also clean up space-before-tab issues in the documentation.
>>
>> Signed-off-by: Andrew Jeffery
>
> Reviewed-by: Linus Walleij
>
On 28/05/2017 15:59, Linus Walleij wrote:
> On Tue, May 16, 2017 at 9:58 AM, Andrew Jeffery wrote:
>
>> Also clean up space-before-tab issues in the documentation.
>>
>> Signed-off-by: Andrew Jeffery
>
> Reviewed-by: Linus Walleij
>
> Does this collide with Daniel's 2500 patch?
>
> Sorry
Hi,
On 28-05-17 19:08, Alan Cox wrote:
On Sun, 28 May 2017 14:30:35 +0200
Hans de Goede wrote:
Do not call dev_warn with a NULL device, this silence the following 2
warnings:
[ 14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO
[ 14.392257] (NULL
Hi,
On 28-05-17 19:08, Alan Cox wrote:
On Sun, 28 May 2017 14:30:35 +0200
Hans de Goede wrote:
Do not call dev_warn with a NULL device, this silence the following 2
warnings:
[ 14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO
[ 14.392257] (NULL device *): Failed to
1 - 100 of 426 matches
Mail list logo