Hi Nick,
Will post next version with the changes you have suggested.
There is a comment below.
On 07/07/2019 03:43 PM, Nicholas Piggin wrote:
Abhishek Goel's on July 4, 2019 7:18 pm:
Currently, the cpuidle governors determine what idle state a idling CPU
should enter into based on heuristics
On Tue, Jul 9, 2019 at 12:52 PM Aneesh Kumar K.V
wrote:
>
> On 7/9/19 7:50 AM, Oliver O'Halloran wrote:
> > On Tue, Jul 9, 2019 at 12:22 AM Aneesh Kumar K.V
> > wrote:
> >>
> >> Christophe Leroy writes:
> >>
> >>> *snip*
> >>> + if (IS_ENABLED(CONFIG_PPC64))
> >>> + isync();
>
Le 08/07/2019 à 21:14, Nathan Chancellor a écrit :
On Mon, Jul 08, 2019 at 11:19:30AM +1000, Michael Ellerman wrote:
On Fri, 2019-05-10 at 09:24:48 UTC, Christophe Leroy wrote:
Cache instructions (dcbz, dcbi, dcbf and dcbst) take two registers
that are summed to obtain the target address.
Wen Yang writes:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
>
> Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
> Signed-off-by: Wen Yang
> Cc: "Rafael J. Wysocki"
> Cc:
Christophe Leroy writes:
> Hi Sven,
>
> Le 08/07/2019 à 12:06, Christophe Leroy a écrit :
>> From: Sven Schnelle
>
> Please describe you patch.
>
> All the changes you are doing to the ppc64 version in order to make it
> generic should be described.
>
> Those changes are also maybe worth
> > > > +
> > > > + /* restore registers by regcache_sync */
> > > > + fsl_esai_register_restore(esai_priv);
> > > > +
> > > > + regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> > > > +ESAI_xCR_xPR_MASK, 0);
> > > > +
On Tue, Jul 9, 2019 at 6:12 AM Claudio Carvalho wrote:
>
> From: Madhavan Srinivasan
>
> Ultravisor provides an in-memory circular buffer containing a message
> log populated with various runtime message produced by firmware.
>
> Based on "powernv/opal-msglog.c", this patch provides a sysfs
On 7/9/19 7:50 AM, Oliver O'Halloran wrote:
On Tue, Jul 9, 2019 at 12:22 AM Aneesh Kumar K.V
wrote:
Christophe Leroy writes:
*snip*
+ if (IS_ENABLED(CONFIG_PPC64))
+ isync();
}
Was checking with Michael about why we need that extra isync. Michael
pointed this came via
On 09-07-19, 07:39, Wen Yang wrote:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
>
> Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
> Signed-off-by: Wen Yang
> Cc: "Rafael J.
> > The np variable is still being used after the of_node_put() call,
>
> > which may result in use-after-free.
>
> > We fix this issue by calling of_node_put() after the last usage.
>
>
> I imagine that this commit description can be improved a bit more
> (by mentioning the influence of
On Tue, Jul 9, 2019 at 12:22 AM Aneesh Kumar K.V
wrote:
>
> Christophe Leroy writes:
>
> > *snip*
> > + if (IS_ENABLED(CONFIG_PPC64))
> > + isync();
> > }
>
>
> Was checking with Michael about why we need that extra isync. Michael
> pointed this came via
>
>
> Hello Wen,
>
> Thanks for your patch!
>
> Did you test your patch with a P.A. Semi board?
>
Hello Christian, thank you.
We don't have a P.A. Semi board yet, so we didn't test it.
If you have such a board, could you please kindly help to test it?
--
Thanks and regards,
Wen
On Fri, Jul 05, 2019 at 07:03:47AM +, S.j. Wang wrote:
> >
> > > +
> > > + /* restore registers by regcache_sync */
> > > + fsl_esai_register_restore(esai_priv);
> > > +
> > > + regmap_update_bits(esai_priv->regmap, REG_ESAI_TCR,
> > > +ESAI_xCR_xPR_MASK,
On 08/07/2019 17:01, alist...@popple.id.au wrote:
Hi Alexey,
Couple of comment/questions below.
- /*
- * Reserve page 0 so it will not be used for any mappings.
- * This avoids buggy drivers that consider page 0 to be invalid
- * to crash the machine or even lose data.
-
The cpu variable is still being used in the of_get_property() call
after the of_node_put() call, which may result in use-after-free.
Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
Signed-off-by: Wen Yang
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc:
On Mon, Jul 08, 2019 at 06:24:04PM -0400, Mimi Zohar wrote:
> Hi Jarkko,
>
> On Mon, 2019-07-08 at 18:11 +0300, Jarkko Sakkinen wrote:
> > On Sat, 2019-07-06 at 20:18 -0400, Nayna Jain wrote:
> > > +/*
> > > + * tpm_get_pcr_allocation() - initialize the chip allocated banks for
> > > PCRs
> > >
On Mon, Jul 08, 2019 at 06:24:04PM -0400, Mimi Zohar wrote:
> > static int tpm_get_pcr_allocation(struct tpm_chip *chip)
> > {
> > int rc;
> >
> > rc = (chip->flags & TPM_CHIP_FLAG_TPM2) ?
> > tpm2_get_pcr_allocation(chip) :
> >
Hi Jarkko,
On Mon, 2019-07-08 at 18:11 +0300, Jarkko Sakkinen wrote:
> On Sat, 2019-07-06 at 20:18 -0400, Nayna Jain wrote:
> > +/*
> > + * tpm_get_pcr_allocation() - initialize the chip allocated banks for PCRs
> > + * @chip: TPM chip to use.
> > + */
> > +static int
Hello Wen,
Thanks for your patch!
Did you test your patch with a P.A. Semi board?
Cheers,
Christian
On 7/8/19 5:53 PM, janani wrote:
> On 2019-06-28 15:08, Claudio Carvalho wrote:
>> From: Sukadev Bhattiprolu
>>
>> To enter a secure guest, we have to go through the ultravisor, therefore
>> we do a ucall when we are entering a secure guest.
>>
>> This change is needed for any sort of entry to
On 2019-06-28 15:08, Claudio Carvalho wrote:
From: Michael Anderson
- Check for MSR_S so that kvmppc_set_msr will include it. Prior to
this
change return to guest would not have the S bit set.
- Patch based on comment from Paul Mackerras
Signed-off-by: Michael Anderson
On 2019-06-28 15:08, Claudio Carvalho wrote:
From: Sukadev Bhattiprolu
To enter a secure guest, we have to go through the ultravisor,
therefore
we do a ucall when we are entering a secure guest.
This change is needed for any sort of entry to the secure guest from
the
hypervisor, whether
On 2019-06-28 15:08, Claudio Carvalho wrote:
When the ultravisor firmware is available, it takes control over the
LDBAR register. In this case, thread-imc updates and save/restore
operations on the LDBAR register are handled by ultravisor.
Signed-off-by: Claudio Carvalho
Reviewed-by: Ram Pai
From: Madhavan Srinivasan
Ultravisor provides an in-memory circular buffer containing a message
log populated with various runtime message produced by firmware.
Based on "powernv/opal-msglog.c", this patch provides a sysfs interface
/sys/firmware/opal/uv_msglog for userspace to view the
On 7/1/19 2:54 AM, Alexey Kardashevskiy wrote:
>
> On 29/06/2019 06:08, Claudio Carvalho wrote:
>> From: Ram Pai
>>
>> Ultravisor is responsible for flushing the tlb cache, since it manages
>> the PATE entries. Hence skip tlb flush, if the ultravisor firmware is
>> available.
>>
>>
On 2019-06-28 15:08, Claudio Carvalho wrote:
From: Ram Pai
Ultravisor is responsible for flushing the tlb cache, since it manages
the PATE entries. Hence skip tlb flush, if the ultravisor firmware is
available.
Signed-off-by: Ram Pai
Signed-off-by: Claudio Carvalho
---
8ddd2249bcb1d9974fb5d28] Merge tag
'for-linus-20190706' of git://git.kernel.dk/linux-block
git bisect good 46713c3d2f8da5e3d8ddd2249bcb1d9974fb5d28
# bad: [d58b5ab90ee7528126fd5833df7fc5bda8331ce8] Add linux-next specific files
for 20190708
git bisect bad d58b5ab90ee7528126fd5833df7fc5bda8331ce8
On 2019-06-28 15:08, Claudio Carvalho wrote:
From: Michael Anderson
When running under an ultravisor, the ultravisor controls the real
partition table and has it in secure memory where the hypervisor can't
access it, and therefore we (the HV) have to do a ucall whenever we
want
to update an
On 2019-06-28 15:08, Claudio Carvalho wrote:
From: Ram Pai
Add the ucall() function, which can be used to make ultravisor calls
with varied number of in and out arguments. Ultravisor calls can be
made
from the host or guests.
This copies the implementation of plpar_hcall().
Signed-off-by:
Hi Christophe,
On Mon, Jul 08, 2019 at 12:40:52PM +0200, Christophe Leroy wrote:
> > From: Sven Schnelle
>
> Please describe you patch.
>
> All the changes you are doing to the ppc64 version in order to make it
> generic should be described.
>
> Those changes are also maybe worth splitting
> @@ -204,6 +205,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy
> *policy)
> out_unmap_sdcasr:
> iounmap(sdcasr_mapbase);
> out:
> + of_node_put(cpu);
I would find the usage of a jump label like “put_node” nicer at such
a source code place.
Regards,
Markus
On 2019-06-28 15:08, Claudio Carvalho wrote:
This feature tells if the ultravisor firmware is available to handle
ucalls.
Signed-off-by: Claudio Carvalho
[ Device node name to "ibm,ultravisor" ]
Signed-off-by: Michael Anderson
Reviewed-by: Janani Janakiraman
---
On 2019-06-28 15:08, Claudio Carvalho wrote:
From: Sukadev Bhattiprolu
The ultravisor processor mode is introduced in POWER platforms that
supports the Protected Execution Facility (PEF). Ultravisor is higher
privileged than hypervisor mode.
In PEF enabled platforms, the MSR_S bit is used to
> The np variable is still being used after the of_node_put() call,
> which may result in use-after-free.
> We fix this issue by calling of_node_put() after the last usage.
I imagine that this commit description can be improved a bit more
(by mentioning the influence of “immr_node”?).
How do
On Fri, Jul 05, 2019 at 03:29:39PM +1000, Nicholas Piggin wrote:
Okay. It might be possible to save the address in the kernel and
then notify the driver afterward. For user-mode and any non-atomic
user copy AFAIK the irq_work should practically run synchronously
after the machine check returns
On Sat, 2019-07-06 at 20:25 -0400, Nayna wrote:
> Thanks Jarkko. I just now posted the v2 version that includes your and
> Stefan's feedbacks.
Looks almost legit :-)
/Jarkko
On Sat, 2019-07-06 at 20:18 -0400, Nayna Jain wrote:
> +/*
> + * tpm_get_pcr_allocation() - initialize the chip allocated banks for PCRs
> + * @chip: TPM chip to use.
> + */
> +static int tpm_get_pcr_allocation(struct tpm_chip *chip)
> +{
> + int rc;
> +
> + if (chip->flags &
On Sat, Jul 06, 2019 at 07:56:39PM +1000, Nicholas Piggin wrote:
Santosh Sivaraj's on July 6, 2019 7:26 am:
From: Reza Arbab
Testing my memcpy_mcsafe() work in progress with an injected UE, I get
an error like this immediately after the function returns:
BUG: Unable to handle kernel data
Russell Currey writes:
> Strict module RWX is just like strict kernel RWX, but for modules - so
> loadable modules aren't marked both writable and executable at the same
> time. This is handled by the generic code in kernel/module.c, and
> simply requires the architecture to implement the
Christophe Leroy writes:
> This patch drops the assembly PPC64 version of flush_dcache_range()
> and re-uses the PPC32 static inline version.
>
> With GCC 8.1, the following code is generated:
>
> void flush_test(unsigned long start, unsigned long stop)
> {
> flush_dcache_range(start,
https://bugzilla.kernel.org/show_bug.cgi?id=203839
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/include/asm/pgtable.h
between commit:
d6eacedd1f0e ("powerpc/book3s: Use config independent helpers for page table
walk")
from the powerpc tree and commit:
be66a174b253 ("mm/nvdimm: add
Hi Sven,
Le 08/07/2019 à 12:06, Christophe Leroy a écrit :
From: Sven Schnelle
Please describe you patch.
All the changes you are doing to the ppc64 version in order to make it
generic should be described.
Those changes are also maybe worth splitting the patch in several parts,
either
Le 07/07/2019 à 21:21, Sven Schnelle a écrit :
Signed-off-by: Sven Schnelle
---
Please add here a description of the changes done since RFC.
arch/Kconfig | 3 +
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/kexec_elf_64.c | 547
From: Sven Schnelle
Signed-off-by: Sven Schnelle
---
patch generated with 'git format-patch -C' in order to
see the modifications done in kexec_elf.c in addition to
copying it from arch/powerpc/kernel/kexec_elf_64.c
arch/Kconfig | 3 +
Le 08/07/2019 à 02:56, Michael Ellerman a écrit :
Christophe Leroy writes:
To increase readability/maintainability, replace hard coded
instructions values by symbolic names.
Signed-off-by: Christophe Leroy
---
v3: fixed warning by adding () in an 'if' around X | Y (unlike said in v2
On 08-07-19, 16:48, Wen Yang wrote:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
>
> Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
> Signed-off-by: Wen Yang
> Cc: "Rafael J.
The cpu variable is still being used in the of_get_property() call
after the of_node_put() call, which may result in use-after-free.
Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
Signed-off-by: Wen Yang
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc:
> > The cpu variable is still being used in the of_get_property() call
> > after the of_node_put() call, which may result in use-after-free.
> >
> > Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
> > Signed-off-by: Wen Yang
> > Cc: "Rafael J. Wysocki"
> > Cc: Viresh
On 7/6/19 3:23 PM, Nicholas Piggin wrote:
> Santosh Sivaraj's on July 6, 2019 7:26 am:
>> If we take a UE on one of the instructions with a fixup entry, set nip
>> to continue exucution at the fixup entry. Stop processing the event
>> further or print it.
>
> Minor nit, but can you instead a
On 08-07-19, 15:19, Wen Yang wrote:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
>
> Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
> Signed-off-by: Wen Yang
> Cc: "Rafael J.
The cpu variable is still being used in the of_get_property() call
after the of_node_put() call, which may result in use-after-free.
Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
Signed-off-by: Wen Yang
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc:
> > The cpu variable is still being used in the of_get_property() call
> > after the of_node_put() call, which may result in use-after-free.
> >
> > Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
> > Signed-off-by: Wen Yang
> > Cc: "Rafael J. Wysocki"
> > Cc: Viresh
Hi Alexey,
Couple of comment/questions below.
- /*
-* Reserve page 0 so it will not be used for any mappings.
-* This avoids buggy drivers that consider page 0 to be invalid
-* to crash the machine or even lose data.
-*/
- if (tbl->it_offset == 0)
-
It seems this is mostly just enabling already existing code used by KVM
for
on-demand TCE level allocation on baremetal as well. Given that I
suppose the
implementation of the on-demand allocation itself is already used and
therefore somewhat tested by KVM. I took a look at pnv_tce() which does
From: Shengjiu Wang
There is chip errata ERR008000, the reference doc is
(https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf),
The issue is "While using ESAI transmit or receive and
an underrun/overrun happens, channel swap may occur.
The only recovery mechanism is to reset the ESAI."
This issue
From: Shengjiu Wang
Extract the operation to be functions, to improve the
readability.
In this patch, fsl_esai_hw_init, fsl_esai_register_restore,
fsl_esai_trigger_start and fsl_esai_trigger_stop are
extracted.
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
sound/soc/fsl/fsl_esai.c
From: Shengjiu Wang
recover the channel swap after xrun
Shengjiu Wang (2):
ASoC: fsl_esai: Wrap some operations to be functions
ASoC: fsl_esai: recover the channel swap after xrun
sound/soc/fsl/fsl_esai.c | 270 ---
1 file changed, 197 insertions(+), 73
On 08-07-19, 14:19, Wen Yang wrote:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
>
> Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
> Signed-off-by: Wen Yang
> Cc: "Rafael J.
The cpu variable is still being used in the of_get_property() call
after the of_node_put() call, which may result in use-after-free.
Fixes: a9acc26b75f ("cpufreq/pasemi: fix possible object reference leak")
Signed-off-by: Wen Yang
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc:
When CONFIG_PPC_IRQ_SOFT_MASK_DEBUG is enabled (uncommon), we have a
series of WARN_ON's in arch_local_irq_restore().
These are "should never happen" conditions, but if they do happen they
can flood the console and render the system unusable. So switch them
to WARN_ON_ONCE().
Fixes: e2b36d591720
61 matches
Mail list logo
