From: Shengjiu Wang
[ Upstream commit b776c4a4618ec1b5219d494c423dc142f23c4e8f ]
There may be failure when start 1 channel recording after
8 channels recording. The reason is that the CHnF
flags are not cleared successfully by software reset.
This issue is triggerred by the change of clearing
From: Shengjiu Wang
[ Upstream commit 292709b9cf3ba470af94b62c9bb60284cc581b79 ]
SRES is self-cleared bit, but REG_MICFIL_CTRL1 is defined as
non volatile register, it still remain in regmap cache after set,
then every update of REG_MICFIL_CTRL1, software reset happens.
to avoid this, clear it
Sathvika Vasireddy wrote:
On 29/11/22 20:58, Christophe Leroy wrote:
Le 29/11/2022 à 16:13, Sathvika Vasireddy a écrit :
Hi all,
On 25/11/22 09:00, Stephen Rothwell wrote:
Hi all,
After merging the powerpc-objtool tree, today's linux-next build (powerpc
pseries_le_defconfig) produced
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit
from the type. Generic MM currently only uses 5 bits for the type
(MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused.
While at it, mask the type in mk_swap_pte() as well.
Note that 32bit alpha has 64bit PTEs but only
We want to implement __HAVE_ARCH_PTE_SWP_EXCLUSIVE on all architectures.
Let's extend our sanity checks, especially testing that our PTE bit
does not affect:
* is_swap_pte() -> pte_present() and pte_none()
* the swap entry + type
* pte_swp_soft_dirty()
Especially, the pfn_pte() is dodgy when the
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit
from the type. Generic MM currently only uses 5 bits for the type
(MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused.
While at it, also mask the type in mk_swap_pte().
Note that this bit does not conflict with swap PMDs
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using bit 6 in the PTE,
reducing the swap type in the !CONFIG_X2TLB case to 5 bits. Generic MM
currently only uses 5 bits for the type (MAX_SWAPFILES_SHIFT), so the
stolen bit is effectively unused.
Interrestingly, the swap type in the !CONFIG_X2TLB
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using bit 10, which is
yet unused for swap PTEs.
The pte_mkuptodate() is a bit weird in __pte_to_swp_entry() for a swap PTE
... but it only messes with bit 1 and 2 and there is a comment in
set_pte(), so leave these bits alone.
While at it, mask the
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the
offset. This reduces the maximum swap space per file to 16 GiB (was 32
GiB).
While at it, mask the type in __swp_entry().
Cc: Brian Cain
Signed-off-by: David Hildenbrand
---
arch/hexagon/include/asm/pgtable.h | 37
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit
from the type. Generic MM currently only uses 5 bits for the type
(MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused.
While at it, mask the type in __swp_entry().
Cc: Stefan Kristiansson
Cc: Stafford Horne
On Tue, Dec 06, 2022 at 11:37:26AM +, Wei Liu wrote:
> On Mon, Dec 05, 2022 at 11:36:39PM +0800, Dawei Li wrote:
> > Since commit fc7a6209d571 ("bus: Make remove callback return
> > void") forces bus_type::remove be void-returned, it doesn't
> > make much sense for any bus based driver
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit
from the type. Generic MM currently only uses 5 bits for the type
(MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused.
While at it, also mask the type in __swp_entry().
Signed-off-by: David Hildenbrand
---
The definitions are not required, let's remove them.
Cc: Geert Uytterhoeven
Cc: Greg Ungerer
Signed-off-by: David Hildenbrand
---
arch/m68k/include/asm/pgtable_no.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/m68k/include/asm/pgtable_no.h
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit
from the type. Generic MM currently only uses 5 bits for the type
(MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused.
While at it, make sure for sun3 that the valid bit never gets set by
properly masking it off and mask
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using the yet-unused
_PAGE_ACCESSED location in the swap PTE. Looking at pte_present()
and pte_none() checks, there seems to be no actual reason why we cannot
use it: we only have to make sure we're not using _PAGE_PRESENT.
Reusing this bit avoids
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by reusing the SRMMU_DIRTY
bit as that seems to be safe to reuse inside a swap PTE. This avoids
having to steal one bit from the swap offset.
While at it, relocate the swap PTE layout documentation and use the same
style now used for most other archs.
Supported by all architectures that support swp PTEs, so let's drop it.
Signed-off-by: David Hildenbrand
---
arch/alpha/include/asm/pgtable.h | 1 -
arch/arc/include/asm/pgtable-bits-arcv2.h| 1 -
arch/arm/include/asm/pgtable.h | 1 -
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the
offset. This reduces the maximum swap space per file to 64 GiB (was 128
GiB).
While at it drop the PTE_TYPE_FAULT from __swp_entry_to_pte() which is
defined to be 0 and is rather confusing because we should be dealing
with
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit
from the type. Generic MM currently only uses 5 bits for the type
(MAX_SWAPFILES_SHIFT), so the stolen bit was effectively unused.
While at it, mask the type in __swp_entry().
Cc: "David S. Miller"
Signed-off-by: David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using bit 5, which is yet
unused. The only important parts seems to be to not use _PAGE_PRESENT
(bit 9).
Cc: Vineet Gupta
Signed-off-by: David Hildenbrand
---
arch/arc/include/asm/pgtable-bits-arcv2.h | 27 ---
1 file changed,
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit
from the type. Generic MM currently only uses 5 bits for the type
(MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused.
The shift by 2 when converting between PTE and arch-specific swap entry
makes the swap PTE layout a
nios2 disables swap for a good reason: it doesn't even provide
sufficient type bits as required by core MM. However, swap entries are
nowadays also used for other purposes (migration entries,
PTE markers, HWPoison, ...), and accidential use could be problematic.
Let's properly use 5 bits for the
We already implemented support for 64bit book3s in commit bff9beaa2e80
("powerpc/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE for book3s")
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE also in 32bit by reusing yet
unused LSB 2 / MSB 29. There seems to be no real reason why that bit cannot
be
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE just like we already do on
x86-64. After deciphering the PTE layout it becomes clear that there are
still unused bits for 2-level and 3-level page tables that we should be
able to use. Reusing a bit avoids stealing one bit from the swap offset.
While at
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using bit 1. This
bit should be safe to use for our usecase.
Most importantly, we can still distinguish swap PTEs from PAGE_NONE PTEs
(see pte_present()) and don't use one of the two reserved attribute
masks (1101 and ). Attribute mask 1100 and
On Mon, Dec 05, 2022 at 05:00:52PM +0100, Greg KH wrote:
> On Mon, Dec 05, 2022 at 11:36:38PM +0800, Dawei Li wrote:
> > For bus-based driver, device removal is implemented as:
> > device_remove() => bus->remove() => driver->remove()
> >
> > Driver core needs no feedback from bus driver about the
On 2022-12-05 17:50, Michael Ellerman wrote:
Michael Jeanson writes:
On 2022-12-05 15:11, Michael Jeanson wrote:
Michael Jeanson writes:
In v5.7 the powerpc syscall entry/exit logic was rewritten in C, on
PPC64_ELF_ABI_V1 this resulted in the symbols in the syscall table
changing from their
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the
offset. This reduces the maximum swap space per file to 16 GiB (was 32
GiB).
We might actually be able to reuse one of the other software bits
(_PAGE_READ / PAGE_WRITE) instead, because we only have to keep
pte_present(),
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE.
On 64bit, steal one bit from the type. Generic MM currently only uses 5
bits for the type (MAX_SWAPFILES_SHIFT), so the stolen bit is effectively
unused.
On 32bit we're able to locate unused bits. As the PTE layout for 32 bit
is very confusing,
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using the yet-unused bit
31.
Cc: Thomas Bogendoerfer
Signed-off-by: David Hildenbrand
---
arch/nios2/include/asm/pgtable-bits.h | 3 +++
arch/nios2/include/asm/pgtable.h | 22 +-
2 files changed, 24 insertions(+), 1
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit
from the offset. This reduces the maximum swap space per file: on 32bit
to 16 GiB (was 32 GiB).
Note that this bit does not conflict with swap PMDs and could also be used
in swap PMD context later.
While at it, mask the type in
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on 32bit and 64bit.
On 64bit, let's use MSB 56 (LSB 7), located right next to the page type.
On 32bit, let's use LSB 2 to avoid stealing one bit from the swap offset.
There seems to be no real reason why these bits cannot be used for swap
PTEs. The
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 5d562c48a21eeb029a8fd3f18e1b31fd83660474 Add linux-next specific
files for 20221206
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211231857.0dmueoa1-...@intel.com
https
From: Shengjiu Wang
[ Upstream commit b776c4a4618ec1b5219d494c423dc142f23c4e8f ]
There may be failure when start 1 channel recording after
8 channels recording. The reason is that the CHnF
flags are not cleared successfully by software reset.
This issue is triggerred by the change of clearing
From: Shengjiu Wang
[ Upstream commit 292709b9cf3ba470af94b62c9bb60284cc581b79 ]
SRES is self-cleared bit, but REG_MICFIL_CTRL1 is defined as
non volatile register, it still remain in regmap cache after set,
then every update of REG_MICFIL_CTRL1, software reset happens.
to avoid this, clear it
From: Shengjiu Wang
[ Upstream commit b776c4a4618ec1b5219d494c423dc142f23c4e8f ]
There may be failure when start 1 channel recording after
8 channels recording. The reason is that the CHnF
flags are not cleared successfully by software reset.
This issue is triggerred by the change of clearing
From: Shengjiu Wang
[ Upstream commit 292709b9cf3ba470af94b62c9bb60284cc581b79 ]
SRES is self-cleared bit, but REG_MICFIL_CTRL1 is defined as
non volatile register, it still remain in regmap cache after set,
then every update of REG_MICFIL_CTRL1, software reset happens.
to avoid this, clear it
On Mon, Dec 05, 2022 at 11:36:39PM +0800, Dawei Li wrote:
> Since commit fc7a6209d571 ("bus: Make remove callback return
> void") forces bus_type::remove be void-returned, it doesn't
> make much sense for any bus based driver implementing remove
> callbalk to return non-void to its caller.
>
>
On 12/2/22 10:49, Geert Uytterhoeven wrote:
"make dtbs_check":
arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dtb: i2cswitch@70:
$nodename:0: 'i2cswitch@70' does not match '^(i2c-?)?mux'
From schema:
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
This is the follow-up on [1]:
[PATCH v2 0/8] mm: COW fixes part 3: reliable GUP R/W FOLL_GET of
anonymous pages
After we implemented __HAVE_ARCH_PTE_SWP_EXCLUSIVE on most prominent
enterprise architectures, implement __HAVE_ARCH_PTE_SWP_EXCLUSIVE on all
remaining architectures
Hi Bjorn
On Tue, Dec 06, 2022 at 12:09:56PM -0600, Bjorn Helgaas wrote:
> On Wed, Sep 28, 2022 at 02:03:55PM +0300, Serge Semin wrote:
> > On Wed, Sep 28, 2022 at 06:59:40PM +0800, Zhuo Chen wrote:
> > > There is no need to clear error status during init code, so remove it.
> >
> > Why do you
On Wed, Sep 28, 2022 at 02:03:55PM +0300, Serge Semin wrote:
> On Wed, Sep 28, 2022 at 06:59:40PM +0800, Zhuo Chen wrote:
> > There is no need to clear error status during init code, so remove it.
>
> Why do you think there isn't? Justify in more details.
Thanks for taking a look, Sergey! I
Hi Zhuo,
On Wed, Sep 28, 2022 at 06:59:45PM +0800, Zhuo Chen wrote:
> When state is pci_channel_io_frozen in pcie_do_recovery(), the
> severity is fatal and fatal error status should be cleared.
> So add pci_aer_clear_fatal_status().
>
> Signed-off-by: Zhuo Chen
> ---
> drivers/pci/pcie/err.c
[moved James, Dick, LPFC supporters to "to"]
On Wed, Sep 28, 2022 at 06:59:41PM +0800, Zhuo Chen wrote:
> lpfc_aer_cleanup_state() requires clearing both fatal and non-fatal
> uncorrectable error status.
I don't know what the point of lpfc_aer_cleanup_state() is. AER
errors should be handled
-kselftests
x86_64 defconfig
x86_64 rhel-8.3-func
arm randconfig-r046-20221206
i386 randconfig-a014
arc randconfig-r043-20221206
i386 randconfig-a012
i386
Rohan McLure writes:
> The check that a higher-level entry in multi-level pages contains a page
> translation entry (pte) is performed by p{m,u,4}d_leaf stubs, which may
> be specialised for each choice of mmu. In a prior commit, we replace
> uses to the catch-all stubs, p{m,u,4}d_is_leaf with
Rohan McLure writes:
> On creation and clearing of a page table mapping, instrument such calls
> by invoking page_table_check_pte_set and page_table_check_pte_clear
> respectively. These calls serve as a sanity check against illegal
> mappings.
>
> Enable ARCH_SUPPORTS_PAGE_TABLE_CHECK for all
Great job spotting this. Somehow lost these throughout the revisions. Thanks.
> On 7 Dec 2022, at 9:24 am, Michael Ellerman wrote:
>
> Rohan McLure writes:
>> The check that a higher-level entry in multi-level pages contains a page
>> translation entry (pte) is performed by p{m,u,4}d_leaf
Le 06/12/2022 à 15:38, Mathieu Desnoyers a écrit :
> On 2022-12-05 17:50, Michael Ellerman wrote:
>> Michael Jeanson writes:
>>> On 2022-12-05 15:11, Michael Jeanson wrote:
>>> Michael Jeanson writes:
In v5.7 the powerpc syscall entry/exit logic was rewritten in C, on
Mathieu Desnoyers writes:
> On 2022-12-05 17:50, Michael Ellerman wrote:
>> Michael Jeanson writes:
>>> On 2022-12-05 15:11, Michael Jeanson wrote:
>>> Michael Jeanson writes:
In v5.7 the powerpc syscall entry/exit logic was rewritten in C, on
PPC64_ELF_ABI_V1 this
Quoting Sean Anderson (2022-11-01 16:27:21)
> On 11/1/22 16:10, Stephen Boyd wrote:
> >>
> >> Oh, I remember why I did this. I need the reference clock for
> >> clk_hw_round_rate,
> >> which is AFAICT the only correct way to implement round_rate.
> >>
> >
> > Is the reference clk the parent of
51 matches
Mail list logo