The documentation of Qualcomm's SPMI PMIC voltage ADC claims that the
'reg' property consists of two values, the SPMI address and the length
of the controller's registers. However the SPMI bus to which it is added
specifies "#size-cells = <0>;". Remove the controller register length
from the
This series adds the DT node for the QCOM SPMI PMIC5 ADC and a channel
for the die temperature.
The die temperature is going to be used by the temperature alarm driver
(https://lore.kernel.org/patchwork/project/lkml/list/?series=361416).
My understanding is that some of the ADC channels are/can
This adds the adc node to pm8998 based on the examples in the
bindings. It also fixes the order of the included headers.
Signed-off-by: Matthias Kaehlcke
--
Changes in v2:
- removed io-channel-ranges attribute
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 12 +++-
1 file changed, 11
This adds the adc node to pm8998 based on the examples in the
bindings. It also fixes the order of the included headers.
Signed-off-by: Matthias Kaehlcke
--
Changes in v2:
- removed io-channel-ranges attribute
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 12 +++-
1 file changed, 11
Add a channel node for the die temperature to the ADC.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
Signed-off-by: Matthias Kaehlcke
--
Changes in v2:
- none
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git
Add a channel node for the die temperature to the ADC.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
Signed-off-by: Matthias Kaehlcke
--
Changes in v2:
- none
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git
Hi Rob,
On 09/05/18 14:31, Rob Herring wrote:
> On Wed, Sep 5, 2018 at 4:10 PM Frank Rowand wrote:
>>
>> On 09/05/18 13:06, Rob Herring wrote:
>>> On Wed, Sep 5, 2018 at 1:19 PM Frank Rowand wrote:
On 09/05/18 04:51, Rob Herring wrote:
> On Tue, Sep 4, 2018 at 8:49 PM Frank Rowand
Hi Rob,
On 09/05/18 14:31, Rob Herring wrote:
> On Wed, Sep 5, 2018 at 4:10 PM Frank Rowand wrote:
>>
>> On 09/05/18 13:06, Rob Herring wrote:
>>> On Wed, Sep 5, 2018 at 1:19 PM Frank Rowand wrote:
On 09/05/18 04:51, Rob Herring wrote:
> On Tue, Sep 4, 2018 at 8:49 PM Frank Rowand
at 1:25 PM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 07:58:40PM +, Nadav Amit wrote:
>>> With that CR3 trickery, we can rid ourselves of the text_mutex
>>> requirement, since concurrent text_poke is 'safe'. That would clean up
>>> the kgdb code quite a bit.
>>
>> I don’t know. I’m
at 1:25 PM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 07:58:40PM +, Nadav Amit wrote:
>>> With that CR3 trickery, we can rid ourselves of the text_mutex
>>> requirement, since concurrent text_poke is 'safe'. That would clean up
>>> the kgdb code quite a bit.
>>
>> I don’t know. I’m
On Thu, 06 Sep 2018, Peter Zijlstra wrote:
On Fri, Jul 20, 2018 at 01:05:59PM -0700, Davidlohr Bueso wrote:
On Fri, 20 Jul 2018, Andrew Morton wrote:
>I'm surprised. Is spin_lock_irqsave() significantly more expensive
>than spin_lock_irq()? Relative to all the other stuff those functions
On Thu, 06 Sep 2018, Peter Zijlstra wrote:
On Fri, Jul 20, 2018 at 01:05:59PM -0700, Davidlohr Bueso wrote:
On Fri, 20 Jul 2018, Andrew Morton wrote:
>I'm surprised. Is spin_lock_irqsave() significantly more expensive
>than spin_lock_irq()? Relative to all the other stuff those functions
Hi Marcel,
Boris Brezillon wrote on Thu, 6 Sep 2018
22:44:22 +0200:
> On Thu, 6 Sep 2018 10:49:22 +0200
> Marcel Ziswiler wrote:
>
> > From: Marcel Ziswiler
> >
> > This patch enables support to read the ECC level from the NAND flash
> > using ESMT SLC NAND ID byte 5 information as
Hi Marcel,
Boris Brezillon wrote on Thu, 6 Sep 2018
22:44:22 +0200:
> On Thu, 6 Sep 2018 10:49:22 +0200
> Marcel Ziswiler wrote:
>
> > From: Marcel Ziswiler
> >
> > This patch enables support to read the ECC level from the NAND flash
> > using ESMT SLC NAND ID byte 5 information as
On Thu, 6 Sep 2018 10:49:22 +0200
Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> This patch enables support to read the ECC level from the NAND flash
> using ESMT SLC NAND ID byte 5 information as documented e.g. in the
> following data sheet:
>
>
On Thu, 6 Sep 2018 10:49:22 +0200
Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> This patch enables support to read the ECC level from the NAND flash
> using ESMT SLC NAND ID byte 5 information as documented e.g. in the
> following data sheet:
>
>
On Thu, 6 Sep 2018 10:49:21 +0200
Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Reorder NAND manufacturer ids for clarity.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> drivers/mtd/nand/raw/nand_ids.c | 20 ++--
> include/linux/mtd/rawnand.h | 8
> 2
On Thu, 6 Sep 2018 10:49:21 +0200
Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Reorder NAND manufacturer ids for clarity.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> drivers/mtd/nand/raw/nand_ids.c | 20 ++--
> include/linux/mtd/rawnand.h | 8
> 2
On Thu, Sep 06, 2018 at 03:20:46PM -0500, Brijesh Singh wrote:
>
>
> On 09/06/2018 02:47 PM, Sean Christopherson wrote:
> ...
>
> >>
> >>Yes, the auxiliary array will dumped into the regular .bss when
> >>CONFIG_AMD_MEM_ENCRYPT=n. Typically it will be few k, I am not
> >>sure if its worth
On Thu, Sep 06, 2018 at 03:20:46PM -0500, Brijesh Singh wrote:
>
>
> On 09/06/2018 02:47 PM, Sean Christopherson wrote:
> ...
>
> >>
> >>Yes, the auxiliary array will dumped into the regular .bss when
> >>CONFIG_AMD_MEM_ENCRYPT=n. Typically it will be few k, I am not
> >>sure if its worth
On 9/6/2018 1:29 PM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 01:05:05PM -0700, Reinette Chatre wrote:
>> When I separate the above into the two functions it just becomes either:
>>rdpmcl(l2_hit_pmcnum, l2_hits_after);
>>rdpmcl(l2_miss_pmcnum,
On 9/6/2018 1:29 PM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 01:05:05PM -0700, Reinette Chatre wrote:
>> When I separate the above into the two functions it just becomes either:
>>rdpmcl(l2_hit_pmcnum, l2_hits_after);
>>rdpmcl(l2_miss_pmcnum,
On Thu, Sep 06, 2018 at 11:34:32AM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, Aug 27, 2018 at 10:10 AM, Matthias Kaehlcke wrote:
> > On Fri, Aug 10, 2018 at 05:09:17PM -0700, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Wed, Aug 8, 2018 at 12:13 PM, Matthias Kaehlcke
> >> wrote:
> >> > This
On Thu, Sep 06, 2018 at 11:34:32AM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, Aug 27, 2018 at 10:10 AM, Matthias Kaehlcke wrote:
> > On Fri, Aug 10, 2018 at 05:09:17PM -0700, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Wed, Aug 8, 2018 at 12:13 PM, Matthias Kaehlcke
> >> wrote:
> >> > This
The mini2440 computer uses "active high" to signal that the "write protect"
of the inserted MMC is set. The current code uses the opposite, leading to
a wrong detection of write protection. The solution is simply to use
".wprotect_invert = 1" in the description of the MMC.
Signed-off-by: Cedric
The mini2440 computer uses "active high" to signal that the "write protect"
of the inserted MMC is set. The current code uses the opposite, leading to
a wrong detection of write protection. The solution is simply to use
".wprotect_invert = 1" in the description of the MMC.
Signed-off-by: Cedric
On Thu, Aug 30, 2018 at 02:50:39PM +0300, Andy Shevchenko wrote:
> Switch to bitmap_zalloc() to show clearly what we are allocating.
> Besides that it returns pointer of bitmap type instead of opaque void *.
>
> Signed-off-by: Andy Shevchenko
> ---
> arch/x86/kernel/cpu/intel_rdt.c | 10
On Wed, 5 Sep 2018, Igor Stoppa wrote:
> WARN_ON() already contains an unlikely(), so it's not necessary to wrap it
> into another.
>
> Signed-off-by: Igor Stoppa
> Acked-by: Kees Cook
> Cc: linux-security-mod...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
Applied to
On Thu, Aug 30, 2018 at 02:50:39PM +0300, Andy Shevchenko wrote:
> Switch to bitmap_zalloc() to show clearly what we are allocating.
> Besides that it returns pointer of bitmap type instead of opaque void *.
>
> Signed-off-by: Andy Shevchenko
> ---
> arch/x86/kernel/cpu/intel_rdt.c | 10
On Wed, 5 Sep 2018, Igor Stoppa wrote:
> WARN_ON() already contains an unlikely(), so it's not necessary to wrap it
> into another.
>
> Signed-off-by: Igor Stoppa
> Acked-by: Kees Cook
> Cc: linux-security-mod...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
Applied to
On Thu, 2018-08-23 at 18:47 +1000, Nicholas Piggin wrote:
> There is no need to call this from tlb_flush_mmu_tlbonly, it
> logically belongs with tlb_flush_mmu_free. This allows some
> code consolidation with a subsequent fix.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: Rik van Riel
This
On Thu, 2018-08-23 at 18:47 +1000, Nicholas Piggin wrote:
> There is no need to call this from tlb_flush_mmu_tlbonly, it
> logically belongs with tlb_flush_mmu_free. This allows some
> code consolidation with a subsequent fix.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: Rik van Riel
This
On Thu, Sep 06, 2018 at 01:05:05PM -0700, Reinette Chatre wrote:
> When I separate the above into the two functions it just becomes either:
>rdpmcl(l2_hit_pmcnum, l2_hits_after);
>rdpmcl(l2_miss_pmcnum, l2_miss_after);
> or:
>
On Thu, Sep 06, 2018 at 01:05:05PM -0700, Reinette Chatre wrote:
> When I separate the above into the two functions it just becomes either:
>rdpmcl(l2_hit_pmcnum, l2_hits_after);
>rdpmcl(l2_miss_pmcnum, l2_miss_after);
> or:
>
> And what about populate_pud?
> set_pud(pud, pud_mkhuge(pfn_pud(cpa->pfn,
>canon_pgprot(pud_pgprot;
>
> start += PUD_SIZE;
> cpa->pfn += PUD_SIZE;
Yes you're right. That case needs to be fixed too.
Are
> And what about populate_pud?
> set_pud(pud, pud_mkhuge(pfn_pud(cpa->pfn,
>canon_pgprot(pud_pgprot;
>
> start += PUD_SIZE;
> cpa->pfn += PUD_SIZE;
Yes you're right. That case needs to be fixed too.
Are
On Thu, Sep 06, 2018 at 01:12:14PM -0700, Nadav Amit wrote:
> at 12:57 PM, Peter Zijlstra wrote:
>
> > On Sun, Sep 02, 2018 at 11:14:50AM -0700, Nadav Amit wrote:
> >> When page-table entries are set, the compiler might optimize their
> >> assignment by using multiple instructions to set the
On Thu, Sep 06, 2018 at 01:12:14PM -0700, Nadav Amit wrote:
> at 12:57 PM, Peter Zijlstra wrote:
>
> > On Sun, Sep 02, 2018 at 11:14:50AM -0700, Nadav Amit wrote:
> >> When page-table entries are set, the compiler might optimize their
> >> assignment by using multiple instructions to set the
On Thu, Sep 06, 2018 at 07:58:40PM +, Nadav Amit wrote:
> > With that CR3 trickery, we can rid ourselves of the text_mutex
> > requirement, since concurrent text_poke is 'safe'. That would clean up
> > the kgdb code quite a bit.
>
> I don’t know. I’m somewhat worried with multiple mechanisms
On Thu, Sep 06, 2018 at 07:58:40PM +, Nadav Amit wrote:
> > With that CR3 trickery, we can rid ourselves of the text_mutex
> > requirement, since concurrent text_poke is 'safe'. That would clean up
> > the kgdb code quite a bit.
>
> I don’t know. I’m somewhat worried with multiple mechanisms
On 09/06/2018 02:47 PM, Sean Christopherson wrote:
...
Yes, the auxiliary array will dumped into the regular .bss when
CONFIG_AMD_MEM_ENCRYPT=n. Typically it will be few k, I am not
sure if its worth complicating the code to save those extra memory.
Most of the distro's have
On 09/06/2018 02:47 PM, Sean Christopherson wrote:
...
Yes, the auxiliary array will dumped into the regular .bss when
CONFIG_AMD_MEM_ENCRYPT=n. Typically it will be few k, I am not
sure if its worth complicating the code to save those extra memory.
Most of the distro's have
Hi,
On Thu, Sep 6, 2018 at 1:12 PM, Bjorn Andersson
wrote:
>> * Seems to have a few rails named differently LDO22 is named
>> "vreg_l22a_2p95" in your DTS but "vreg_l22a_2p85" in mine as one
>> example. The schematics I have (from Dec 5, 2017) show it as 2p85.
>>
>
> Looks like a typo on my
Hi,
On Thu, Sep 6, 2018 at 1:12 PM, Bjorn Andersson
wrote:
>> * Seems to have a few rails named differently LDO22 is named
>> "vreg_l22a_2p95" in your DTS but "vreg_l22a_2p85" in mine as one
>> example. The schematics I have (from Dec 5, 2017) show it as 2p85.
>>
>
> Looks like a typo on my
Currently, when a reader acquires a lock, it only sets the
RWSEM_READER_OWNED bit in the owner field. The other bits are simply
not used. When debugging hanging cases involving rwsems and readers,
the owner value does not provide much useful information at all.
This patch modifies the current
Currently, when a reader acquires a lock, it only sets the
RWSEM_READER_OWNED bit in the owner field. The other bits are simply
not used. When debugging hanging cases involving rwsems and readers,
the owner value does not provide much useful information at all.
This patch modifies the current
Hi Baolin,
Thank you for the patch. I really appreciate your effort.
I see one more thing I forgot to mention in the previous
review. Please take a look at my comment to pattern_set().
On 09/06/2018 04:37 AM, Baolin Wang wrote:
> This patch implements the 'pattern_set'and 'pattern_clear'
>
Hi Baolin,
Thank you for the patch. I really appreciate your effort.
I see one more thing I forgot to mention in the previous
review. Please take a look at my comment to pattern_set().
On 09/06/2018 04:37 AM, Baolin Wang wrote:
> This patch implements the 'pattern_set'and 'pattern_clear'
>
Hi Marcel,
Marcel Ziswiler wrote on Thu, 6 Sep 2018
10:49:21 +0200:
> From: Marcel Ziswiler
>
> Reorder NAND manufacturer ids for clarity.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
Both patches applied to nand/next with subject prefix s/nand:/rawnand:/
as well as upper-case:
Hi Marcel,
Marcel Ziswiler wrote on Thu, 6 Sep 2018
10:49:21 +0200:
> From: Marcel Ziswiler
>
> Reorder NAND manufacturer ids for clarity.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
Both patches applied to nand/next with subject prefix s/nand:/rawnand:/
as well as upper-case:
at 12:57 PM, Peter Zijlstra wrote:
> On Sun, Sep 02, 2018 at 11:14:50AM -0700, Nadav Amit wrote:
>> When page-table entries are set, the compiler might optimize their
>> assignment by using multiple instructions to set the PTE. This might
>> turn into a security hazard if the user somehow
at 12:57 PM, Peter Zijlstra wrote:
> On Sun, Sep 02, 2018 at 11:14:50AM -0700, Nadav Amit wrote:
>> When page-table entries are set, the compiler might optimize their
>> assignment by using multiple instructions to set the PTE. This might
>> turn into a security hazard if the user somehow
On Thu 06 Sep 10:52 PDT 2018, Doug Anderson wrote:
> Bjorn,
>
> On Sat, Sep 1, 2018 at 3:19 PM, Bjorn Andersson
> wrote:
> > Add regulator definitions for pm8998 and pmi8998 regulators on the MTP.
> >
> > Signed-off-by: Bjorn Andersson
> > ---
> > arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 216
On Thu 06 Sep 10:52 PDT 2018, Doug Anderson wrote:
> Bjorn,
>
> On Sat, Sep 1, 2018 at 3:19 PM, Bjorn Andersson
> wrote:
> > Add regulator definitions for pm8998 and pmi8998 regulators on the MTP.
> >
> > Signed-off-by: Bjorn Andersson
> > ---
> > arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 216
Hi Hans,
With regards,
Suman
-Original Message-
From: Hans de Goede
Sent: Thursday, September 6, 2018 1:06 PM
To: Suman Tripathi ; ax...@kernel.dk;
t...@kernel.org; linux-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
j...@perches.com;
Hi Hans,
With regards,
Suman
-Original Message-
From: Hans de Goede
Sent: Thursday, September 6, 2018 1:06 PM
To: Suman Tripathi ; ax...@kernel.dk;
t...@kernel.org; linux-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
j...@perches.com;
Hi,
On 06-09-18 20:05, Suman Tripathi wrote:
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Trpathi
Signed-off-by: Rameshwar Prasad Sahu
Sorry, but the patch is still coming
Hi,
On 06-09-18 20:05, Suman Tripathi wrote:
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Trpathi
Signed-off-by: Rameshwar Prasad Sahu
Sorry, but the patch is still coming
Hi Peter,
On 9/6/2018 12:44 PM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 12:21:59PM -0700, Reinette Chatre wrote:
>> If you do have suggestions on how I can improve the implementation while
>> maintaining (or improving) the accuracy of the measurements I would
>> greatly appreciate it.
>
Hi Peter,
On 9/6/2018 12:44 PM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 12:21:59PM -0700, Reinette Chatre wrote:
>> If you do have suggestions on how I can improve the implementation while
>> maintaining (or improving) the accuracy of the measurements I would
>> greatly appreciate it.
>
On Mon, Aug 27, 2018 at 10:21:51AM +0200, Johan Hovold wrote:
> Use the new of_get_compatible_child() helper to lookup the mdio-internal
> child node instead of using of_find_compatible_node(), which searches
> the entire tree from a given start node and thus can return an unrelated
> (i.e.
On Mon, Aug 27, 2018 at 10:21:51AM +0200, Johan Hovold wrote:
> Use the new of_get_compatible_child() helper to lookup the mdio-internal
> child node instead of using of_find_compatible_node(), which searches
> the entire tree from a given start node and thus can return an unrelated
> (i.e.
at 12:53 PM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 07:42:14PM +, Nadav Amit wrote:
>> at 12:40 PM, Peter Zijlstra wrote:
>>
>>> On Sun, Sep 02, 2018 at 10:32:19AM -0700, Nadav Amit wrote:
text_mutex is expected to be held before text_poke() is called, but we
cannot add
at 12:53 PM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 07:42:14PM +, Nadav Amit wrote:
>> at 12:40 PM, Peter Zijlstra wrote:
>>
>>> On Sun, Sep 02, 2018 at 10:32:19AM -0700, Nadav Amit wrote:
text_mutex is expected to be held before text_poke() is called, but we
cannot add
On Sun, Sep 02, 2018 at 11:14:50AM -0700, Nadav Amit wrote:
> When page-table entries are set, the compiler might optimize their
> assignment by using multiple instructions to set the PTE. This might
> turn into a security hazard if the user somehow manages to use the
> interim PTE. L1TF does not
On Sun, Sep 02, 2018 at 11:14:50AM -0700, Nadav Amit wrote:
> When page-table entries are set, the compiler might optimize their
> assignment by using multiple instructions to set the PTE. This might
> turn into a security hazard if the user somehow manages to use the
> interim PTE. L1TF does not
On Thu, Sep 06, 2018 at 07:42:14PM +, Nadav Amit wrote:
> at 12:40 PM, Peter Zijlstra wrote:
>
> > On Sun, Sep 02, 2018 at 10:32:19AM -0700, Nadav Amit wrote:
> >> text_mutex is expected to be held before text_poke() is called, but we
> >> cannot add a lockdep assertion since kgdb does not
On Thu, Sep 06, 2018 at 07:42:14PM +, Nadav Amit wrote:
> at 12:40 PM, Peter Zijlstra wrote:
>
> > On Sun, Sep 02, 2018 at 10:32:19AM -0700, Nadav Amit wrote:
> >> text_mutex is expected to be held before text_poke() is called, but we
> >> cannot add a lockdep assertion since kgdb does not
On 09/06/2018 02:24 PM, Brijesh Singh wrote:
...
Again we have to consider the bare metal scenario while doing this. The
aux array you proposed will be added in decrypted section only when
CONFIG_AMD_MEM_ENCRYPT=y. If CONFIG_AMD_MEM_ENCRYPT=n then nothng
gets put in .data.decrypted
On 09/06/2018 02:24 PM, Brijesh Singh wrote:
...
Again we have to consider the bare metal scenario while doing this. The
aux array you proposed will be added in decrypted section only when
CONFIG_AMD_MEM_ENCRYPT=y. If CONFIG_AMD_MEM_ENCRYPT=n then nothng
gets put in .data.decrypted
On Thu, Sep 06, 2018 at 02:24:32PM -0500, Brijesh Singh wrote:
>
>
> On 09/06/2018 01:47 PM, Sean Christopherson wrote:
> >On Thu, Sep 06, 2018 at 01:37:50PM -0500, Brijesh Singh wrote:
> >>
> >>
> >>On 09/06/2018 09:18 AM, Sean Christopherson wrote:
> >>
> >>
> >
> >So are we going
On Thu, Sep 06, 2018 at 02:24:32PM -0500, Brijesh Singh wrote:
>
>
> On 09/06/2018 01:47 PM, Sean Christopherson wrote:
> >On Thu, Sep 06, 2018 at 01:37:50PM -0500, Brijesh Singh wrote:
> >>
> >>
> >>On 09/06/2018 09:18 AM, Sean Christopherson wrote:
> >>
> >>
> >
> >So are we going
On Thu, Sep 06, 2018 at 12:21:59PM -0700, Reinette Chatre wrote:
> If you do have suggestions on how I can improve the implementation while
> maintaining (or improving) the accuracy of the measurements I would
> greatly appreciate it.
You can reduce the code duplication by using __always_inline
On Thu, Sep 06, 2018 at 12:21:59PM -0700, Reinette Chatre wrote:
> If you do have suggestions on how I can improve the implementation while
> maintaining (or improving) the accuracy of the measurements I would
> greatly appreciate it.
You can reduce the code duplication by using __always_inline
arm64? Because KernelCI is seeing build failures in arm64
> defconfig for next-20180906
> Clearly it's a module build problem for sunxi but I'm not sure who to
> CC about this.
>
> https://kernelci.org/build/next/branch/master/kernel/next-20180906/
> https://storage.kernelci.org/
arm64? Because KernelCI is seeing build failures in arm64
> defconfig for next-20180906
> Clearly it's a module build problem for sunxi but I'm not sure who to
> CC about this.
>
> https://kernelci.org/build/next/branch/master/kernel/next-20180906/
> https://storage.kernelci.org/
at 12:40 PM, Peter Zijlstra wrote:
> On Sun, Sep 02, 2018 at 10:32:19AM -0700, Nadav Amit wrote:
>> text_mutex is expected to be held before text_poke() is called, but we
>> cannot add a lockdep assertion since kgdb does not take it, and instead
>> *supposedly* ensures the lock is not taken and
at 12:40 PM, Peter Zijlstra wrote:
> On Sun, Sep 02, 2018 at 10:32:19AM -0700, Nadav Amit wrote:
>> text_mutex is expected to be held before text_poke() is called, but we
>> cannot add a lockdep assertion since kgdb does not take it, and instead
>> *supposedly* ensures the lock is not taken and
On Thu, Sep 6, 2018 at 9:38 PM, Theodore Y. Ts'o wrote:
> On Thu, Sep 06, 2018 at 09:41:04AM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:b36fdc6853a3 Merge tag 'gpio-v4.19-2' of git://git.kernel...
>> git tree: upstream
>> console output:
On Thu, Sep 6, 2018 at 9:38 PM, Theodore Y. Ts'o wrote:
> On Thu, Sep 06, 2018 at 09:41:04AM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:b36fdc6853a3 Merge tag 'gpio-v4.19-2' of git://git.kernel...
>> git tree: upstream
>> console output:
On Sun, Sep 02, 2018 at 10:32:19AM -0700, Nadav Amit wrote:
> text_mutex is expected to be held before text_poke() is called, but we
> cannot add a lockdep assertion since kgdb does not take it, and instead
> *supposedly* ensures the lock is not taken and will not be acquired by
> any other core
On Sun, Sep 02, 2018 at 10:32:19AM -0700, Nadav Amit wrote:
> text_mutex is expected to be held before text_poke() is called, but we
> cannot add a lockdep assertion since kgdb does not take it, and instead
> *supposedly* ensures the lock is not taken and will not be acquired by
> any other core
On Thu, Sep 06, 2018 at 09:41:04AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:b36fdc6853a3 Merge tag 'gpio-v4.19-2' of git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1716bc9e40
>
On Thu, Sep 06, 2018 at 09:41:04AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:b36fdc6853a3 Merge tag 'gpio-v4.19-2' of git://git.kernel...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1716bc9e40
>
On 2018-09-06 12:43:49 [-0400], Steven Rostedt wrote:
> > Your tree (v4.14.63) has
> > 80d20d35af1ed ("nohz: Fix local_timer_softirq_pending()")
> > 0a0e0829f9901 ("nohz: Fix missing tick reprogram when interrupting an
> > inline softirq")
> >
> > which means that the patch
On 2018-09-06 12:43:49 [-0400], Steven Rostedt wrote:
> > Your tree (v4.14.63) has
> > 80d20d35af1ed ("nohz: Fix local_timer_softirq_pending()")
> > 0a0e0829f9901 ("nohz: Fix missing tick reprogram when interrupting an
> > inline softirq")
> >
> > which means that the patch
On Thu, Sep 06, 2018 at 10:21:38AM -0700, Dave Hansen wrote:
> There's probably a massive number of things that would break if we
> assumed sane 64-bit writes can be observed piecemeal.
Do assume, it has been observed. WRITE_ONCE()/READ_ONCE() are _required_
if you cannot have load/store tearing.
On Thu, Sep 06, 2018 at 10:21:38AM -0700, Dave Hansen wrote:
> There's probably a massive number of things that would break if we
> assumed sane 64-bit writes can be observed piecemeal.
Do assume, it has been observed. WRITE_ONCE()/READ_ONCE() are _required_
if you cannot have load/store tearing.
On 09/06/2018 01:47 PM, Sean Christopherson wrote:
On Thu, Sep 06, 2018 at 01:37:50PM -0500, Brijesh Singh wrote:
On 09/06/2018 09:18 AM, Sean Christopherson wrote:
So are we going to be defining a decrypted section for every piece of
machinery now?
That's a bit too much in my
On 09/06/2018 01:47 PM, Sean Christopherson wrote:
On Thu, Sep 06, 2018 at 01:37:50PM -0500, Brijesh Singh wrote:
On 09/06/2018 09:18 AM, Sean Christopherson wrote:
So are we going to be defining a decrypted section for every piece of
machinery now?
That's a bit too much in my
Hi Peter,
On 9/6/2018 7:15 AM, Peter Zijlstra wrote:
> On Thu, Aug 16, 2018 at 01:16:08PM -0700, Reinette Chatre wrote:
>> +l2_miss_event = perf_event_create_kernel_counter(_miss_attr,
>> + plr->cpu,
>> +
Hi Peter,
On 9/6/2018 7:15 AM, Peter Zijlstra wrote:
> On Thu, Aug 16, 2018 at 01:16:08PM -0700, Reinette Chatre wrote:
>> +l2_miss_event = perf_event_create_kernel_counter(_miss_attr,
>> + plr->cpu,
>> +
; >> total: 134 pass: 133 fail: 1
>>
>> Do you build arm64? Because KernelCI is seeing build failures in arm64
>> defconfig for next-20180906
>> Clearly it's a module build problem for sunxi but I'm not sure who to
>> CC about this.
>>
> I do, b
; >> total: 134 pass: 133 fail: 1
>>
>> Do you build arm64? Because KernelCI is seeing build failures in arm64
>> defconfig for next-20180906
>> Clearly it's a module build problem for sunxi but I'm not sure who to
>> CC about this.
>>
> I do, b
On Thu, Sep 06, 2018 at 06:38:30PM +, Nadav Amit wrote:
> Note that patch 1/6 is still needed to fix false lockdep shoutouts due to a
> recent patch.
For some reason I do not appear to have 1/6 in my inbox. Let me dig
through lkml.
On Thu, Sep 06, 2018 at 06:38:30PM +, Nadav Amit wrote:
> Note that patch 1/6 is still needed to fix false lockdep shoutouts due to a
> recent patch.
For some reason I do not appear to have 1/6 in my inbox. Let me dig
through lkml.
On Fri, Jul 20, 2018 at 01:05:59PM -0700, Davidlohr Bueso wrote:
> On Fri, 20 Jul 2018, Andrew Morton wrote:
> >I'm surprised. Is spin_lock_irqsave() significantly more expensive
> >than spin_lock_irq()? Relative to all the other stuff those functions
> >are doing? If so, how come? Some
On Fri, Jul 20, 2018 at 01:05:59PM -0700, Davidlohr Bueso wrote:
> On Fri, 20 Jul 2018, Andrew Morton wrote:
> >I'm surprised. Is spin_lock_irqsave() significantly more expensive
> >than spin_lock_irq()? Relative to all the other stuff those functions
> >are doing? If so, how come? Some
On Sun, Sep 02, 2018 at 07:32:50PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix kernel-doc warning:
>
> ../drivers/pci/pci.c:218: warning: Excess function parameter 'p' description
> in 'pci_dev_str_match_path'
>
> Signed-off-by: Randy Dunlap
> Cc: Bjorn Helgaas
> Cc:
On Sun, Sep 02, 2018 at 07:32:50PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix kernel-doc warning:
>
> ../drivers/pci/pci.c:218: warning: Excess function parameter 'p' description
> in 'pci_dev_str_match_path'
>
> Signed-off-by: Randy Dunlap
> Cc: Bjorn Helgaas
> Cc:
701 - 800 of 1950 matches
Mail list logo
