Hi Long,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on v4.17-rc6]
[cannot apply to cifs/for-next next-20180601]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Long,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on v4.17-rc6]
[cannot apply to cifs/for-next next-20180601]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
An AMD POGO check in shpchp incorrectly included any device with device ID
0x7458, no matter what the vendor.
Also, use pci_info() instead of dbg() for messages related to OSHP.
They're important enough that they should appear in dmesg.
I intend to include these along with Mika's shpchp updates.
From: Bjorn Helgaas
Use dev_printk() for messages related to requesting control of SHPC hotplug
via the OSHP method.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/hotplug/acpi_pcihp.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git
From: Bjorn Helgaas
The fix for an AMD POGO erratum related to SHPC incorrectly identified the
device. The workaround should be applied only for AMD POGO devices, but it
was instead applied to:
- all AMD bridges, and
- all devices from any vendor with device ID 0x7458
Fixes: 53044f357448
An AMD POGO check in shpchp incorrectly included any device with device ID
0x7458, no matter what the vendor.
Also, use pci_info() instead of dbg() for messages related to OSHP.
They're important enough that they should appear in dmesg.
I intend to include these along with Mika's shpchp updates.
From: Bjorn Helgaas
Use dev_printk() for messages related to requesting control of SHPC hotplug
via the OSHP method.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/hotplug/acpi_pcihp.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git
From: Bjorn Helgaas
The fix for an AMD POGO erratum related to SHPC incorrectly identified the
device. The workaround should be applied only for AMD POGO devices, but it
was instead applied to:
- all AMD bridges, and
- all devices from any vendor with device ID 0x7458
Fixes: 53044f357448
On Sat, 02 Jun 2018, Herbert Xu wrote:
tbl = bucket_table_alloc(ht, size, GFP_KERNEL);
- if (tbl == NULL)
- return -ENOMEM;
+ if (unlikely(tbl == NULL)) {
+ size = min_t(u16, ht->p.min_size, HASH_MIN_SIZE);
You mean max_t?
Not really. I
On Sat, 02 Jun 2018, Herbert Xu wrote:
tbl = bucket_table_alloc(ht, size, GFP_KERNEL);
- if (tbl == NULL)
- return -ENOMEM;
+ if (unlikely(tbl == NULL)) {
+ size = min_t(u16, ht->p.min_size, HASH_MIN_SIZE);
You mean max_t?
Not really. I
From: Stephen Boyd
We only have two users of the debug_init hook, and we recently stopped
caring about the return value from that op. Finish that off by changing
the clk_op to return void instead of int because it doesn't matter if
debugfs fails or not.
Cc: Eric Anholt
Cc: David Lechner
Cc:
From: Stephen Boyd
We only have two users of the debug_init hook, and we recently stopped
caring about the return value from that op. Finish that off by changing
the clk_op to return void instead of int because it doesn't matter if
debugfs fails or not.
Cc: Eric Anholt
Cc: David Lechner
Cc:
On Fri, 2018-06-01 at 20:35 -0700, Andy Lutomirski wrote:
> On Fri, Jun 1, 2018 at 3:13 PM Rik van Riel wrote:
> >
> > On Fri, 1 Jun 2018 14:21:58 -0700
> > Andy Lutomirski wrote:
> >
> > > Hmm. I wonder if there's a more clever data structure than a
> > > bitmap
> > > that we could be using
On Fri, 2018-06-01 at 20:35 -0700, Andy Lutomirski wrote:
> On Fri, Jun 1, 2018 at 3:13 PM Rik van Riel wrote:
> >
> > On Fri, 1 Jun 2018 14:21:58 -0700
> > Andy Lutomirski wrote:
> >
> > > Hmm. I wonder if there's a more clever data structure than a
> > > bitmap
> > > that we could be using
Quoting Geert Uytterhoeven (2018-06-01 12:22:33)
> Hi Stephen,
>
> On Fri, Jun 1, 2018 at 9:20 PM, Stephen Boyd wrote:
> > Quoting Geert Uytterhoeven (2018-05-18 03:58:40)
> >> __of_clk_get() calls of_parse_phandle_with_args(), which rejects
> >> negative indices since commit bd69f73f2c81eed9
Quoting Geert Uytterhoeven (2018-06-01 12:22:33)
> Hi Stephen,
>
> On Fri, Jun 1, 2018 at 9:20 PM, Stephen Boyd wrote:
> > Quoting Geert Uytterhoeven (2018-05-18 03:58:40)
> >> __of_clk_get() calls of_parse_phandle_with_args(), which rejects
> >> negative indices since commit bd69f73f2c81eed9
On Fri, Jun 01, 2018 at 09:01:25AM -0700, Davidlohr Bueso wrote:
> Update the test module as such.
>
> Signed-off-by: Davidlohr Bueso
Please drop this patch.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Jun 01, 2018 at 09:01:25AM -0700, Davidlohr Bueso wrote:
> Update the test module as such.
>
> Signed-off-by: Davidlohr Bueso
Please drop this patch.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Jun 01, 2018 at 09:01:22AM -0700, Davidlohr Bueso wrote:
>
> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
> index 05a4b1b8b8ce..ae17da6f0c75 100644
> --- a/lib/rhashtable.c
> +++ b/lib/rhashtable.c
> @@ -175,7 +175,7 @@ static struct bucket_table *bucket_table_alloc(struct
>
On Fri, Jun 01, 2018 at 09:01:22AM -0700, Davidlohr Bueso wrote:
>
> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
> index 05a4b1b8b8ce..ae17da6f0c75 100644
> --- a/lib/rhashtable.c
> +++ b/lib/rhashtable.c
> @@ -175,7 +175,7 @@ static struct bucket_table *bucket_table_alloc(struct
>
Hi,
Looking at the crash some more, it seems that if value_len > PAGE_SIZE
then e_buf->max_size is rounded up nearest page size [1]. If a new
attribute is added with value_len < e_buf->max_size - EA_SIZE(ea) then
no new space is allocated for the attiribute list [2] and this
triggers the KASAN
Hi,
Looking at the crash some more, it seems that if value_len > PAGE_SIZE
then e_buf->max_size is rounded up nearest page size [1]. If a new
attribute is added with value_len < e_buf->max_size - EA_SIZE(ea) then
no new space is allocated for the attiribute list [2] and this
triggers the KASAN
On Sat, Jun 02, 2018 at 04:42:56AM +0100, Al Viro wrote:
> _If_ I'm interpreting that correctly, that should be something like a bitmap
> of attributes to modify + values to set for each. Let's see -
> propagation 1 + 2 bits
> nodev 1 + 1
> noexec 1 + 1
>
On Sat, Jun 02, 2018 at 04:42:56AM +0100, Al Viro wrote:
> _If_ I'm interpreting that correctly, that should be something like a bitmap
> of attributes to modify + values to set for each. Let's see -
> propagation 1 + 2 bits
> nodev 1 + 1
> noexec 1 + 1
>
On Sat, Jun 02, 2018 at 04:09:14AM +0100, Al Viro wrote:
> On Fri, Jun 01, 2018 at 09:27:43AM +0100, David Howells wrote:
> > Al Viro wrote:
> >
> > > > Instead of overloading this on open having a specific syscalls just
> > > > seems like a much saner idea.
> > >
> > > It's not just mount API;
On Sat, Jun 02, 2018 at 04:09:14AM +0100, Al Viro wrote:
> On Fri, Jun 01, 2018 at 09:27:43AM +0100, David Howells wrote:
> > Al Viro wrote:
> >
> > > > Instead of overloading this on open having a specific syscalls just
> > > > seems like a much saner idea.
> > >
> > > It's not just mount API;
On Fri, 2018-06-01 at 13:03 -0700, Andy Lutomirski wrote:
>
> Mike, you never did say: do you have PCID on your CPU?
Yes.
> Also, what is
> your workload doing to cause so many switches back and forth between
> init_mm and a task.
pipe-test measures pipe round trip, does nearly nothing but
On Fri, 2018-06-01 at 13:03 -0700, Andy Lutomirski wrote:
>
> Mike, you never did say: do you have PCID on your CPU?
Yes.
> Also, what is
> your workload doing to cause so many switches back and forth between
> init_mm and a task.
pipe-test measures pipe round trip, does nearly nothing but
On Fri, Jun 1, 2018 at 6:33 PM, Stephen Rothwell wrote:
> Hi Darrick,
>
> On Fri, 1 Jun 2018 17:59:48 -0700 "Darrick J. Wong"
> wrote:
>>
>> > + if (!dax_enabled) {
>> > - pr_debug("VFS (%s): error: dax support not enabled\n",
>> > - sb->s_id);
>> > +
On Fri, Jun 1, 2018 at 6:33 PM, Stephen Rothwell wrote:
> Hi Darrick,
>
> On Fri, 1 Jun 2018 17:59:48 -0700 "Darrick J. Wong"
> wrote:
>>
>> > + if (!dax_enabled) {
>> > - pr_debug("VFS (%s): error: dax support not enabled\n",
>> > - sb->s_id);
>> > +
On Fri, Jun 1, 2018 at 3:13 PM Rik van Riel wrote:
>
> On Fri, 1 Jun 2018 14:21:58 -0700
> Andy Lutomirski wrote:
>
> > Hmm. I wonder if there's a more clever data structure than a bitmap
> > that we could be using here. Each CPU only ever needs to be in one
> > mm's cpumask, and each cpu only
On Fri, Jun 1, 2018 at 3:13 PM Rik van Riel wrote:
>
> On Fri, 1 Jun 2018 14:21:58 -0700
> Andy Lutomirski wrote:
>
> > Hmm. I wonder if there's a more clever data structure than a bitmap
> > that we could be using here. Each CPU only ever needs to be in one
> > mm's cpumask, and each cpu only
On Fri, Jun 01, 2018 at 09:27:43AM +0100, David Howells wrote:
> Al Viro wrote:
>
> > > Instead of overloading this on open having a specific syscalls just
> > > seems like a much saner idea.
> >
> > It's not just mount API; these can be used independently of that.
> > Think of the uses where
On Fri, Jun 01, 2018 at 09:27:43AM +0100, David Howells wrote:
> Al Viro wrote:
>
> > > Instead of overloading this on open having a specific syscalls just
> > > seems like a much saner idea.
> >
> > It's not just mount API; these can be used independently of that.
> > Think of the uses where
Hi Anson,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on v4.17-rc7 next-20180601]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Anson,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on v4.17-rc7 next-20180601]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Currently we show event_count instead of wakeup_count as part of per
device wakeup_count sysfs attribute. Change it to wakeup_count to make
it more meaningful.
Signed-off-by: Ravi Chandra Sadineni
---
drivers/base/power/sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Currently we show event_count instead of wakeup_count as part of per
device wakeup_count sysfs attribute. Change it to wakeup_count to make
it more meaningful.
Signed-off-by: Ravi Chandra Sadineni
---
drivers/base/power/sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed, 2018-05-30 at 17:03 +0530, Rajneesh Bhardwaj wrote:
> On Wed, May 30, 2018 at 03:53:12AM -0700, David E. Box wrote:
>
> Hi Dave,
>
> > Hi Rajneesh,
> >
> > On Mon, 2018-05-28 at 12:30 +0530, Rajneesh Bhardwaj wrote:
> > > On Thu, May 24, 2018 at 06:10:56PM -0700, David E. Box wrote:
> >
On Wed, 2018-05-30 at 17:03 +0530, Rajneesh Bhardwaj wrote:
> On Wed, May 30, 2018 at 03:53:12AM -0700, David E. Box wrote:
>
> Hi Dave,
>
> > Hi Rajneesh,
> >
> > On Mon, 2018-05-28 at 12:30 +0530, Rajneesh Bhardwaj wrote:
> > > On Thu, May 24, 2018 at 06:10:56PM -0700, David E. Box wrote:
> >
Add the QCOM RPMh regulator driver to manage PMIC regulators
which are controlled via RPMh on some Qualcomm Technologies, Inc.
SoCs. RPMh is a hardware block which contains several
accelerators which are used to manage various hardware resources
that are shared between the processors of the SoC.
Add the QCOM RPMh regulator driver to manage PMIC regulators
which are controlled via RPMh on some Qualcomm Technologies, Inc.
SoCs. RPMh is a hardware block which contains several
accelerators which are used to manage various hardware resources
that are shared between the processors of the SoC.
This patch series adds a driver and device tree binding documentation for
PMIC regulator control via Resource Power Manager-hardened (RPMh) on some
Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block
which contains several accelerators which are used to manage various
Introduce bindings for RPMh regulator devices found on some
Qualcomm Technlogies, Inc. SoCs. These devices allow a given
processor within the SoC to make PMIC regulator requests which
are aggregated within the RPMh hardware block along with requests
from other processors in the SoC to determine
This patch series adds a driver and device tree binding documentation for
PMIC regulator control via Resource Power Manager-hardened (RPMh) on some
Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block
which contains several accelerators which are used to manage various
Introduce bindings for RPMh regulator devices found on some
Qualcomm Technlogies, Inc. SoCs. These devices allow a given
processor within the SoC to make PMIC regulator requests which
are aggregated within the RPMh hardware block along with requests
from other processors in the SoC to determine
Hi Darrick,
On Fri, 1 Jun 2018 17:59:48 -0700 "Darrick J. Wong"
wrote:
>
> > + if (!dax_enabled) {
> > - pr_debug("VFS (%s): error: dax support not enabled\n",
> > - sb->s_id);
> > + pr_debug("%s: error: dax support not enabled\n",
> > +
Hi Darrick,
On Fri, 1 Jun 2018 17:59:48 -0700 "Darrick J. Wong"
wrote:
>
> > + if (!dax_enabled) {
> > - pr_debug("VFS (%s): error: dax support not enabled\n",
> > - sb->s_id);
> > + pr_debug("%s: error: dax support not enabled\n",
> > +
This compatible property was documented before the driver was renamed to
"SBS" (see commit e57f1b68c406 ("devicetree-bindings: Propagate
bq20z75->sbs rename to dt bindings")). The driver has continued to
support this property as an alternative to "sbs,sbs-battery", and
because we've noticed there
This driver was originally submitted for the TI BQ20Z75 battery IC
(commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge
IC")) and later renamed to express generic SBS support. While it's
mostly true that this driver implemented a standard SBS command set, it
takes liberties
This compatible property was documented before the driver was renamed to
"SBS" (see commit e57f1b68c406 ("devicetree-bindings: Propagate
bq20z75->sbs rename to dt bindings")). The driver has continued to
support this property as an alternative to "sbs,sbs-battery", and
because we've noticed there
This driver was originally submitted for the TI BQ20Z75 battery IC
(commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge
IC")) and later renamed to express generic SBS support. While it's
mostly true that this driver implemented a standard SBS command set, it
takes liberties
- On May 31, 2018, at 1:51 PM, Joel Fernandes, Google
j...@joelfernandes.org wrote:
>> I find it odd to have a "return" in a macro that consists of a
>> do { } while (0). I'm tempted to replace "return" by "break" here,
>> to break the macro do/while (0) loop.
>
> "return;" is also used
- On May 31, 2018, at 1:51 PM, Joel Fernandes, Google
j...@joelfernandes.org wrote:
>> I find it odd to have a "return" in a macro that consists of a
>> do { } while (0). I'm tempted to replace "return" by "break" here,
>> to break the macro do/while (0) loop.
>
> "return;" is also used
Call pm_wakeup_event on every irq. This should help us in identifying if
keyboard was a potential wake reason for the last resume.
Signed-off-by: Ravi Chandra Sadineni
---
V2: Increment the wakeup count only when there is a irq and not when the
method is called internally.
Call pm_wakeup_event on every irq. This should help us in identifying if
keyboard was a potential wake reason for the last resume.
Signed-off-by: Ravi Chandra Sadineni
---
V2: Increment the wakeup count only when there is a irq and not when the
method is called internally.
On 6/1/2018 9:59 AM, Konrad Rzeszutek Wilk wrote:
Hi Konrad,
Thanks for doing this. It was on my to-do list to get this
support out after everything settled down.
Just some questions/comments below.
> The AMD document outlining the SSBD handling
>
On 6/1/2018 9:59 AM, Konrad Rzeszutek Wilk wrote:
Hi Konrad,
Thanks for doing this. It was on my to-do list to get this
support out after everything settled down.
Just some questions/comments below.
> The AMD document outlining the SSBD handling
>
On Fri, Jun 01, 2018 at 06:58:46PM +1000, Stephen Rothwell wrote:
> Hi Dan,
>
> Today's linux-next merge of the nvdimm tree got a conflict in:
>
> drivers/dax/super.c
>
> between commits:
>
> ba23cba9b3bd ("fs: allow per-device dax status checking for filesystems")
> 80660f20252d ("dax:
On Fri, Jun 01, 2018 at 06:58:46PM +1000, Stephen Rothwell wrote:
> Hi Dan,
>
> Today's linux-next merge of the nvdimm tree got a conflict in:
>
> drivers/dax/super.c
>
> between commits:
>
> ba23cba9b3bd ("fs: allow per-device dax status checking for filesystems")
> 80660f20252d ("dax:
From: Pramod Kumar
Update Stingray clock binding document to add additional clock entries
with names matching the latest ASIC datasheet. Also modify a few existing
entries to make their naming more consistent with the rest of the entries
Signed-off-by: Pramod Kumar
Signed-off-by: Ray Jui
---
From: Pramod Kumar
Update Stingray clock binding document to add additional clock entries
with names matching the latest ASIC datasheet. Also modify a few existing
entries to make their naming more consistent with the rest of the entries
Signed-off-by: Pramod Kumar
Signed-off-by: Ray Jui
---
This patch series updates Broadcom Stingray clock entries so they match the
latest ASIC datasheet
This patch series is based off v4.17-rc5 and is available on GIHUB:
repo: https://github.com/Broadcom/arm64-linux.git
branch: sr-clk-v3
Changes since v2:
- Move dt-binding header change to the same
From: Pramod Kumar
Update clock output names in the Stingray clock DT nodes so they match
the binding document and the latest ASIC datasheet. Also add entries
for LCPLL2
Signed-off-by: Pramod Kumar
Signed-off-by: Ray Jui
---
.../boot/dts/broadcom/stingray/stingray-clock.dtsi | 26
From: Pramod Kumar
Update and add Stingray clock definitions and tables so they match the
binding document and the latest ASIC datasheet
Signed-off-by: Pramod Kumar
Signed-off-by: Ray Jui
---
drivers/clk/bcm/clk-sr.c | 135 +--
1 file changed, 120
This patch series updates Broadcom Stingray clock entries so they match the
latest ASIC datasheet
This patch series is based off v4.17-rc5 and is available on GIHUB:
repo: https://github.com/Broadcom/arm64-linux.git
branch: sr-clk-v3
Changes since v2:
- Move dt-binding header change to the same
From: Pramod Kumar
Update clock output names in the Stingray clock DT nodes so they match
the binding document and the latest ASIC datasheet. Also add entries
for LCPLL2
Signed-off-by: Pramod Kumar
Signed-off-by: Ray Jui
---
.../boot/dts/broadcom/stingray/stingray-clock.dtsi | 26
From: Pramod Kumar
Update and add Stingray clock definitions and tables so they match the
binding document and the latest ASIC datasheet
Signed-off-by: Pramod Kumar
Signed-off-by: Ray Jui
---
drivers/clk/bcm/clk-sr.c | 135 +--
1 file changed, 120
On 6/1/2018 12:02 PM, Rob Herring wrote:
On Fri, Jun 1, 2018 at 12:56 PM, Ray Jui wrote:
Hi Rob,
On 5/31/2018 9:25 AM, Rob Herring wrote:
On Fri, May 25, 2018 at 09:45:16AM -0700, Ray Jui wrote:
Update and add Stingray clock definitions and tables so they match the
binding document and
On 6/1/2018 12:02 PM, Rob Herring wrote:
On Fri, Jun 1, 2018 at 12:56 PM, Ray Jui wrote:
Hi Rob,
On 5/31/2018 9:25 AM, Rob Herring wrote:
On Fri, May 25, 2018 at 09:45:16AM -0700, Ray Jui wrote:
Update and add Stingray clock definitions and tables so they match the
binding document and
On Wed, 30 May 2018 at 01:08, Paolo Bonzini wrote:
>
> On 29/05/2018 16:31, Radim Krčmář wrote:
> > 2018-05-29 16:23+0200, Radim Krčmář:
> >> 2018-05-29 14:53+0800, Wanpeng Li:
> >>> From: Wanpeng Li
> >>>
> >>> 'Commit d0659d946be0 ("KVM: x86: add option to advance tscdeadline
> >>> hrtimer
On Wed, 30 May 2018 at 01:08, Paolo Bonzini wrote:
>
> On 29/05/2018 16:31, Radim Krčmář wrote:
> > 2018-05-29 16:23+0200, Radim Krčmář:
> >> 2018-05-29 14:53+0800, Wanpeng Li:
> >>> From: Wanpeng Li
> >>>
> >>> 'Commit d0659d946be0 ("KVM: x86: add option to advance tscdeadline
> >>> hrtimer
Immediately after the platform_device_unregister() the device will be cleaned
up.
Accessing the freed pointer immediately after that will crash the system.
Found this bug when kernel is built with CONFIG_PAGE_POISONING and testing
loading/unloading audio drivers in a loop on Qcom platforms.
Fix
Immediately after the platform_device_unregister() the device will be cleaned
up.
Accessing the freed pointer immediately after that will crash the system.
Found this bug when kernel is built with CONFIG_PAGE_POISONING and testing
loading/unloading audio drivers in a loop on Qcom platforms.
Fix
On Thu, 31 May 2018 16:25:38 +0530
"Naveen N. Rao" wrote:
> Masami Hiramatsu wrote:
> > Clear current_kprobe and enable preemption in kprobe
> > even if pre_handler returns !0.
> >
> > This simplifies function override using kprobes.
> >
> > Jprobe used to require to keep the preemption
On Thu, 31 May 2018 16:25:38 +0530
"Naveen N. Rao" wrote:
> Masami Hiramatsu wrote:
> > Clear current_kprobe and enable preemption in kprobe
> > even if pre_handler returns !0.
> >
> > This simplifies function override using kprobes.
> >
> > Jprobe used to require to keep the preemption
On 01/06/18 23:58, Srinivas Kandagatla wrote:
- of_node_clear_flag(dev->of_node, OF_POPULATED);
- of_node_clear_flag(dev->of_node, OF_POPULATED_BUS);
This change seems to have a side effect during re-probing. I will dig in
bit more to see how best it can be fixed.
thanks,
srini
All the managed resources would be freed by the time release function
is invoked. Handling such memory in qcom_smd_edge_release() would do
bad things.
Found this issue while testing Audio usecase where the dsp is started up
and shutdown in a loop.
This patch fixes this issue by using simple
On 01/06/18 23:58, Srinivas Kandagatla wrote:
- of_node_clear_flag(dev->of_node, OF_POPULATED);
- of_node_clear_flag(dev->of_node, OF_POPULATED_BUS);
This change seems to have a side effect during re-probing. I will dig in
bit more to see how best it can be fixed.
thanks,
srini
All the managed resources would be freed by the time release function
is invoked. Handling such memory in qcom_smd_edge_release() would do
bad things.
Found this issue while testing Audio usecase where the dsp is started up
and shutdown in a loop.
This patch fixes this issue by using simple
On Fri, 01 Jun 2018 16:42:36 +0800 Ian Kent wrote:
> The resulting "autofs-create-autofs-kconfig-and-makefile.patch" should
> now look like
Got it, thanks ;)
On Fri, 01 Jun 2018 16:42:36 +0800 Ian Kent wrote:
> The resulting "autofs-create-autofs-kconfig-and-makefile.patch" should
> now look like
Got it, thanks ;)
On Thu, May 31, 2018 at 05:08:12PM +0300, Alexey Budankov wrote:
>
> Enable complex event names containing [.:=,] symbols to be encoded into Perf
> trace using name= modifier e.g. like this:
>
> perf record -e
> cpu/name=\'OFFCORE_RESPONSE:request=DEMAND_RFO:response=L3_HIT.SNOOP_HITM\',\
>
Immediately after the platform_device_unregister() the device will be cleaned
up.
Accessing the freed pointer immediately after that will crash the system.
Found this bug when kernel is built with CONFIG_PAGE_POISONING and testing
loading/unloading audio drivers in a loop on Qcom platforms.
Fix
On Thu, May 31, 2018 at 05:08:12PM +0300, Alexey Budankov wrote:
>
> Enable complex event names containing [.:=,] symbols to be encoded into Perf
> trace using name= modifier e.g. like this:
>
> perf record -e
> cpu/name=\'OFFCORE_RESPONSE:request=DEMAND_RFO:response=L3_HIT.SNOOP_HITM\',\
>
Immediately after the platform_device_unregister() the device will be cleaned
up.
Accessing the freed pointer immediately after that will crash the system.
Found this bug when kernel is built with CONFIG_PAGE_POISONING and testing
loading/unloading audio drivers in a loop on Qcom platforms.
Fix
dapm_kcontrol_data is freed as part of dapm_kcontrol_free(), leaving the
paths list pointer dangling in the list.
This leads to system crash when we try to unload and reload sound card.
I hit this bug during ADSP crash/reboot test case on Dragon board DB410c.
Below is the kernel BUG with SLAB
dapm_kcontrol_data is freed as part of dapm_kcontrol_free(), leaving the
paths list pointer dangling in the list.
This leads to system crash when we try to unload and reload sound card.
I hit this bug during ADSP crash/reboot test case on Dragon board DB410c.
Below is the kernel BUG with SLAB
On Fri, 1 Jun 2018 14:21:58 -0700
Andy Lutomirski wrote:
> Hmm. I wonder if there's a more clever data structure than a bitmap
> that we could be using here. Each CPU only ever needs to be in one
> mm's cpumask, and each cpu only ever changes its own state in the
> bitmask. And writes are
On Fri, 1 Jun 2018 14:21:58 -0700
Andy Lutomirski wrote:
> Hmm. I wonder if there's a more clever data structure than a bitmap
> that we could be using here. Each CPU only ever needs to be in one
> mm's cpumask, and each cpu only ever changes its own state in the
> bitmask. And writes are
On 6/1/2018 2:31 PM, Brian Norris wrote:
> Hi,
>
> On Fri, Jun 01, 2018 at 10:34:34AM -0700, Guenter Roeck wrote:
>> On Fri, Jun 01, 2018 at 10:23:59AM -0700, Brian Norris wrote:
>>> drivers/power/supply/sbs-battery.c | 54 +-
>>> 1 file changed, 46 insertions(+), 8
On 6/1/2018 2:31 PM, Brian Norris wrote:
> Hi,
>
> On Fri, Jun 01, 2018 at 10:34:34AM -0700, Guenter Roeck wrote:
>> On Fri, Jun 01, 2018 at 10:23:59AM -0700, Brian Norris wrote:
>>> drivers/power/supply/sbs-battery.c | 54 +-
>>> 1 file changed, 46 insertions(+), 8
On Fri 2018-06-01 18:37:36, H. Nikolaus Schaller wrote:
> Hi Pavel,
>
> > Am 01.06.2018 um 18:26 schrieb Pavel Machek :
> >
> > NMEA would not be my first choice, really. I'd propose something very
> > similar to existing /dev/input/eventX, but with wider data types.
>
> Since even Rome wasn't
On Fri 2018-06-01 18:37:36, H. Nikolaus Schaller wrote:
> Hi Pavel,
>
> > Am 01.06.2018 um 18:26 schrieb Pavel Machek :
> >
> > NMEA would not be my first choice, really. I'd propose something very
> > similar to existing /dev/input/eventX, but with wider data types.
>
> Since even Rome wasn't
On Mon, 28 May 2018 19:34:19 +0800
kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -12.0% regression of aim9.disk_rr.ops_per_sec due to commit:
>
>
> commit: 1c758a2202a6b4624d0703013a2c6cfa6e7455aa ("tracing/x86: Update
> syscall trace events to handle new prefixed syscall func
On Mon, 28 May 2018 19:34:19 +0800
kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -12.0% regression of aim9.disk_rr.ops_per_sec due to commit:
>
>
> commit: 1c758a2202a6b4624d0703013a2c6cfa6e7455aa ("tracing/x86: Update
> syscall trace events to handle new prefixed syscall func
Hello Mark,
On 05/31/2018 04:48 AM, Mark Brown wrote:
> On Wed, May 30, 2018 at 04:39:10PM -0700, David Collins wrote:
>> The DRMS modes to use and max allowed current per mode need to be
>> specified at the board level in device tree instead of hard-coded per
>> regulator type in the driver.
Hello Mark,
On 05/31/2018 04:48 AM, Mark Brown wrote:
> On Wed, May 30, 2018 at 04:39:10PM -0700, David Collins wrote:
>> The DRMS modes to use and max allowed current per mode need to be
>> specified at the board level in device tree instead of hard-coded per
>> regulator type in the driver.
On Fri, Jun 1, 2018 at 1:35 PM Rik van Riel wrote:
>
> On Fri, 2018-06-01 at 13:03 -0700, Andy Lutomirski wrote:
> > Mike, you never did say: do you have PCID on your CPU? Also, what is
> > your workload doing to cause so many switches back and forth between
> > init_mm and a task.
> >
> > The
On Fri, Jun 1, 2018 at 1:35 PM Rik van Riel wrote:
>
> On Fri, 2018-06-01 at 13:03 -0700, Andy Lutomirski wrote:
> > Mike, you never did say: do you have PCID on your CPU? Also, what is
> > your workload doing to cause so many switches back and forth between
> > init_mm and a task.
> >
> > The
1 - 100 of 1040 matches
Mail list logo
