On 6/30/22 10:46, Anshuman Khandual wrote:
> __SXXX/__PXXX macros is an unnecessary abstraction layer in creating the
> generic protection_map[] array which is used for vm_get_page_prot(). This
> abstraction layer can be avoided, if the platforms just define the array
> protection_map[] for all
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 2a2aa3f05338270aecbe2492fda910d6c17e0102 Add linux-next specific
files for 20220705
Error/Warning reports:
https://lore.kernel.org/linux-doc/202207051821.3f0erisl-...@intel.com
Error/Warning
When RDRAND was introduced, there was much discussion on whether it
should be trusted and how the kernel should handle that. Initially, two
mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and
"nordrand", a boot-time switch.
Later the thinking evolved. With a properly designed
On July 5, 2022 3:00:04 PM PDT, Borislav Petkov wrote:
>On Tue, Jul 05, 2022 at 02:50:34PM -0700, H. Peter Anvin wrote:
>> It's just math. The only variable is your confidence level, i.e. at
>> what level do you decide that the likelihood of pure chance is way
>> smaller than the likelihood of
[Cc'ing Borislav Petkov , Jonathan McDowell ]
Hi Stefan,
On Thu, 2022-06-30 at 22:26 -0400, Stefan Berger wrote:
> Refactor IMA buffer related functions to make them reusable for carrying
> TPM logs across kexec.
>
> Signed-off-by: Stefan Berger
> Cc: Rob Herring
> Cc: Frank Rowand
> Cc:
On July 5, 2022 12:57:04 PM PDT, Borislav Petkov wrote:
>On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote:
>> Oh, huh. Maybe in that case I should adjust the message to say "consider
>> using `random.trust_cpu=0`," which is the thing that would actually make
>> a security
On Tue, Jul 05, 2022 at 02:50:34PM -0700, H. Peter Anvin wrote:
> It's just math. The only variable is your confidence level, i.e. at
> what level do you decide that the likelihood of pure chance is way
> smaller than the likelihood of hardware failure.
That might be but the likelyhood of certain
On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote:
> Oh, huh. Maybe in that case I should adjust the message to say "consider
> using `random.trust_cpu=0`," which is the thing that would actually make
> a security difference.
Why isn't that option documented in
On Tue, Jul 05, 2022 at 10:29:53AM -0600, Rob Herring wrote:
> On Sat, Jul 2, 2022 at 3:04 PM Darren Stevens wrote:
> >
> > In patch a1a2b7125e10 (Drop static setup of IRQ resource from DT
> > core) we stopped platform_get_resource() from returning the IRQ, as all
> > drivers were supposed to
On Sat, Jul 2, 2022 at 3:04 PM Darren Stevens wrote:
>
> In patch a1a2b7125e10 (Drop static setup of IRQ resource from DT
> core) we stopped platform_get_resource() from returning the IRQ, as all
> drivers were supposed to have switched to platform_get_irq()
> Unfortunately the Freescale EHCI
On 14 September 2021 at 05:59 pm, Christian Zigotzky wrote:
Hello Juergen,
Hello All,
Since the RC1 of kernel 5.13, -smp 2 and -smp 4 don't work with a
virtual e5500 QEMU KVM-HV machine anymore. [1]
I see in the serial console, that the uImage doesn't load. I use the
following QEMU command
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #33 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 301337
--> https://bugzilla.kernel.org/attachment.cgi?id=301337=edit
dmesg (5.19-rc5, outline KASAN, PowerMac G4 DP)
Re-tested on 5.19-rc5 +
On Mon, Jul 04, 2022 at 12:34:08PM +, Christophe Leroy wrote:
> Le 04/07/2022 à 13:45, Peter Zijlstra a écrit :
> > I'm somewhat confused; how is an empty STT_FUNC a valid construct on
> > Power?
>
> So am I. It is likely not a valid construct, but that's what GCC seems
> to generate when
On 02 July 2022 at 11:03 pm, Darren Stevens wrote:
In patch a1a2b7125e10 (Drop static setup of IRQ resource from DT
core) we stopped platform_get_resource() from returning the IRQ, as all
drivers were supposed to have switched to platform_get_irq()
Unfortunately the Freescale EHCI driver in host
On Tue, Jul 05, 2022 at 04:22:35PM +1000, Alexey Kardashevskiy wrote:
> I have not looked into the domains for ages, what is missing here? With this
> on top of 5.19-rc1 VFIO works again on my POWER9 box. Thanks,
Does this solve all the problems or just coherency? It seems like it
should solve
for_each_matching_node() will automatically increase and decrease
the refcount. As there is a reference escaped out into global
'fsl_pci_primary', we should not use of_node_put() anymore.
Fixes: 905e75c46dba ("powerpc/fsl-pci: Unify pci/pcie initialization code")
Signed-off-by: Liang He
---
On Tue, Jul 05, 2022 at 12:08:52PM +0200, Jean Delvare wrote:
> On Tue, 28 Jun 2022 16:03:12 +0200, Uwe Kleine-König wrote:
> > From: Uwe Kleine-König
> >
> > The value returned by an i2c driver's remove function is mostly ignored.
> > (Only an error message is printed if the value is non-zero
On Tue, 28 Jun 2022 16:03:12 +0200, Uwe Kleine-König wrote:
> From: Uwe Kleine-König
>
> The value returned by an i2c driver's remove function is mostly ignored.
> (Only an error message is printed if the value is non-zero that the
> error is ignored.)
>
> So change the prototype of the remove
On 2022-07-05 07:22, Alexey Kardashevskiy wrote:
Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
the Type1 VFIO driver. Recent development though has added a coherency
capability check to the generic part of
On Wed, 2022-06-29 at 16:08 +1000, Michael Ellerman wrote:
> Christophe and Nick have been active in recent years on the mailing
> list
> and making contributions, add them as reviewers.
>
> Paul and Ben are no longer actively reviewing powerpc patches, remove
> them from the reviewers, they're
Historically PPC64 managed to avoid using iommu_ops. The VFIO driver
uses a SPAPR TCE sub-driver and all iommu_ops uses were kept in
the Type1 VFIO driver. Recent development though has added a coherency
capability check to the generic part of VFIO and essentially disabled
VFIO on PPC64.
This
21 matches
Mail list logo
