Hi Bjorn,
On 2024/07/25 03:55 PM, Bjorn Helgaas wrote:
> On Thu, Jul 25, 2024 at 11:15:39PM +0530, Amit Machhiwal wrote:
> > ...
> > The crash in question is a critical issue that we would want to have
> > a fix for soon. And while this is still being figured out, is it
> > okay to go with the fix
On Fri Jun 14, 2024 at 6:38 PM AEST, Nicholas Piggin wrote:
> On Fri Jun 14, 2024 at 11:08 AM AEST, Segher Boessenkool wrote:
> > On Fri, Jun 14, 2024 at 10:43:39AM +1000, Nicholas Piggin wrote:
> > > On Wed Jun 12, 2024 at 6:28 PM AEST, Segher Boessenkool wrote:
> > > > On Wed, Jun 12, 2024 at 02:
On Thu, Jul 25, 2024 at 3:41 PM Peter Xu wrote:
>
> On Thu, Jul 25, 2024 at 11:29:49AM -0700, James Houghton wrote:
> > > - pages += change_pmd_range(tlb, vma, pud, addr, next,
> > > newprot,
> > > +
> > > + if (pud_leaf(pud)) {
> > > + if ((next
Hi Amit,
I try to follow the option which add a OF flag. If Rob is ok with this,
I would suggest to use it instead of V1 patch
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index dda6092e6d3a..a401ed0463d9 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -382,6 +382,
On Thu, Jul 25, 2024 at 11:29:49AM -0700, James Houghton wrote:
> > - pages += change_pmd_range(tlb, vma, pud, addr, next,
> > newprot,
> > +
> > + if (pud_leaf(pud)) {
> > + if ((next - addr != PUD_SIZE) ||
> > + pgtable_
On Thu, Jul 25, 2024 at 11:15:39PM +0530, Amit Machhiwal wrote:
> ...
> The crash in question is a critical issue that we would want to have
> a fix for soon. And while this is still being figured out, is it
> okay to go with the fix I proposed in the V1 of this patch?
v6.10 has been released alre
The pull request you sent on Wed, 24 Jul 2024 23:00:14 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl.git/
> tags/constfy-sysctl-6.11-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b485625078cab3b824a84ce185b6e73733704b5b
Thank you!
--
Dee
On Wed, 24 Jul 2024 at 14:00, Joel Granados wrote:
>
> This is my first time sending out a semantic patch, so get back to me if
> you have issues or prefer some other way of receiving it.
Looks fine to me.
Sometimes if it's just a pure scripting change, people send me the
script itself and just
On Mon, Jul 15, 2024 at 12:22 PM Peter Xu wrote:
>
> This is only relevant to the two archs that support PUD dax, aka, x86_64
> and ppc64. PUD THPs do not yet exist elsewhere, and hugetlb PUDs do not
> count in this case.
>
> DAX have had PUD mappings for years, but change protection path never
>
On Thu, Jul 25, 2024 at 04:58:27PM +0100, Dave Martin wrote:
> I'll post a draft patch separately, since I think the update could
> benefit from separate discussion, but my back-of-the-envelope
> calculation suggests that (before this patch) we are down to 0x90
> bytes of free space (i.e., over 96
Hi Lizhi, Rob,
Sorry for responding late. I got busy with some other things.
On 2024/07/23 02:08 PM, Lizhi Hou wrote:
>
> On 7/23/24 12:54, Rob Herring wrote:
> > On Tue, Jul 23, 2024 at 12:21 PM Lizhi Hou wrote:
> > >
> > > On 7/23/24 09:21, Rob Herring wrote:
> > > > On Mon, Jul 15, 2024 at
On Fri, May 03, 2024 at 02:01:35PM +0100, Joey Gouly wrote:
> Implement the PKEYS interface, using the Permission Overlay Extension.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/include/asm/mmu.h | 1 +
> arch/arm64/include/asm/mmu_context.
Add a new .note section containing type, size, offset and flags of every
xfeature that is present.
This information will be used by debuggers to understand the XSAVE
layout of the machine where the core file has been dumped, and to read
XSAVE registers, especially during cross-platform debugging.
This patch proposes to add an extra .note section in the corefile to
dump the CPUID information of a machine.
This is being done to solve the issue of tools like the debuggers
having to deal with coredumps from machines with varying XSAVE
layouts in spite of having the same XCR0 bits.
The new propo
Hi,
On Fri, May 03, 2024 at 02:01:37PM +0100, Joey Gouly wrote:
> Now that PKEYs support has been implemented, enable it for CPUs that
> support S1POE.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> Acked-by: Catalin Marinas
> ---
> arch/arm64/include/asm/pkeys.h | 2
Hi,
On Fri, May 03, 2024 at 02:01:36PM +0100, Joey Gouly wrote:
> Add PKEY support to signals, by saving and restoring POR_EL0 from the
> stackframe.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> Reviewed-by: Mark Brown
> Acked-by: Szabolcs Nagy
> ---
> arch/arm64
On Mon, Jun 03, 2024 at 02:51:46PM +0530, Amit Daniel Kachhap wrote:
>
>
> On 5/31/24 22:09, Mark Brown wrote:
> > On Tue, May 28, 2024 at 12:26:54PM +0530, Amit Daniel Kachhap wrote:
> > > On 5/3/24 18:31, Joey Gouly wrote:
> >
> > > > +#define POE_MAGIC 0x504f4530
> > > > +struct poe_cont
On Fri, May 03, 2024 at 02:01:33PM +0100, Joey Gouly wrote:
> If a memory fault occurs that is due to an overlay/pkey fault, report that to
> userspace with a SEGV_PKUERR.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/include/asm/traps.h | 1 +
> arc
On Fri, May 03, 2024 at 02:01:31PM +0100, Joey Gouly wrote:
> Modify arch_calc_vm_prot_bits() and vm_get_page_prot() such that the pkey
> value is set in the vm_flags and then into the pgprot value.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/includ
On Fri, May 03, 2024 at 02:01:28PM +0100, Joey Gouly wrote:
> Expose a HWCAP and ID_AA64MMFR3_EL1_S1POE to userspace, so they can be used to
> check if the CPU supports the feature.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
>
> This takes the last bit of HWCAP
On Tue, Jul 16, 2024 at 04:17:12PM +0530, Anshuman Khandual wrote:
>
>
> On 5/3/24 18:31, Joey Gouly wrote:
> > Now that PKEYs support has been implemented, enable it for CPUs that
> > support S1POE.
> >
> > Signed-off-by: Joey Gouly
> > Cc: Catalin Marinas
> > Cc: Will Deacon
> > Acked-by: C
On Fri, May 03, 2024 at 02:01:24PM +0100, Joey Gouly wrote:
> POR_EL0 is a register that can be modified by userspace directly,
> so it must be context switched.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/include/asm/cpufeature.h | 6 ++
> arc
Hi,
On Fri, May 03, 2024 at 02:01:22PM +0100, Joey Gouly wrote:
> Allow EL0 or EL1 to access POR_EL0 without being trapped to EL2.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> Acked-by: Catalin Marinas
> ---
> arch/arm64/include/asm/el2_setup.h | 10 +-
> 1
On Thu, 25 Jul 2024 11:22:53 +0800, Shengjiu Wang wrote:
> The static snd_soc_dai_link_components cause conflict for multiple
> instances of this generic driver. For example, when there is
> wm8962 and SPDIF case enabled together, the contaminated
> snd_soc_dai_link_components will cause another de
On Thu, Jul 25, 2024 at 01:35:46PM +0200, Wouter Verhelst wrote:
> NBD actually exports a flag for rotational devices; it's defined in
> nbd.h in the NBD userland source as
>
> #define NBD_FLAG_ROTATIONAL (1 << 4)/* Use elevator algorithm -
> rotational media */
>
> which is passed i
On Mon, Jun 17, 2024 at 08:04:41AM +0200, Christoph Hellwig wrote:
> Use the chance to switch to defaulting to non-rotational and require
> the driver to opt into rotational, which matches the polarity of the
> sysfs interface.
[...]
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index
On Wed, 24 Jul 2024, Luca Ceresoli wrote:
> The of_property_for_each_u32() macro needs five parameters, two of which
> are primarily meant as internal variables for the macro itself (in the
> for() clause). Yet these two parameters are used by a few drivers, and this
> can be considered misuse or
Hi Catalin,
On Tue, Jun 18 2024, Catalin Marinas wrote:
> On Tue, Apr 09, 2024 at 09:17:55AM +0300, Baruch Siach wrote:
>> of_dma_get_max_cpu_address() returns the highest CPU address that
>> devices can use for DMA. The implicit assumption is that all CPU
>> addresses below that limit are suitabl
On i.MX9x platforms, the REG_MICFIL_FSYNC_CTRL, REG_MICFIL_VERID,
REG_MICFIL_PARAM are added, but they are not existed on i.MX8x
platforms.
Use the existed micfil->soc->use_verid to distinguish the access
permission for these platforms.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_micfil.
On the i.MX9x platforms, the mask of FIFO watermark
is 0x1F, on i.MX8x platforms, the mask of FIFO watermark
is 0X7. So use the mask 0x1F for all platforms to make them
compatible.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_micfil.c | 2 +-
sound/soc/fsl/fsl_micfil.h | 2 +-
2 files chan
There are some register difference for i.MX8 and i.MX9
REG_MICFIL_FIFO_CTRL definition is updated.
REG_MICFIL_FSYNC_CTRL, REG_MICFIL_VERID, REG_MICFIL_PARAM are added from
i.MX9
Shengjiu Wang (2):
ASoC: fsl_micfil: Expand the range of FIFO watermark mask
ASoC: fsl_micfil: Differentiate registe
31 matches
Mail list logo
