On 30/05/2024 16:46, Esben Haabendal wrote:
> With CONFIG_FSL_IFC now being user-visible, and thus changed from a select
> to depends in CONFIG_MTD_NAND_FSL_IFC, the dependencies needs to be
> selected in defconfigs.
>
> Signed-off-by: Esben Haabendal
Anyone is going to pick this up?
Reviewed-b
On 30/05/2024 16:46, Esben Haabendal wrote:
> With CONFIG_FSL_IFC now being user-visible, and thus changed from a select
> to depends in CONFIG_MTD_NAND_FSL_IFC, the dependencies needs to be
> selected in defconfig.
>
> Signed-off-by: Esben Haabendal
Reviewed-by: Krzysztof Kozlowski
Best regar
On 27.06.24 02:54, Alistair Popple wrote:
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be managed the same as normal pages
introduce dax_insert_pfn_pud. This will map the entire PUD-sized folio
and take references as it would for a normally
On 27.06.24 02:54, Alistair Popple wrote:
Currently to map a DAX page the DAX driver calls vmf_insert_pfn. This
creates a special devmap PTE entry for the pfn but does not take a
reference on the underlying struct page for the mapping. This is
because DAX page refcounts are treated specially, as
On Mon, Jul 01, 2024 at 04:22:19PM +0800, Oliver Sang wrote:
> from below, it seems the patchset doesn't introduce any performance
> improvement
> but a regression now. is this expected?
Not having the improvement at least alleviate my concerns about data
integrity. I'm still curious where it co
On 24-07-01, Sergei Shtylyov wrote:
> On 7/1/24 4:53 PM, Marco Felsch wrote:
>
> > Provide a simple helper to make it easy to detect an master mtd device.
> >
> > Signed-off-by: Marco Felsch
> > ---
> > include/linux/mtd/mtd.h | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a
On Mon, Jul 1, 2024 at 3:54 PM Marco Felsch wrote:
>
> All kernel users are shifted to the new MTD_EEPROM_AT24 Kconfig symbol
> so we can drop the old one.
>
Nope, with this series arm64 still selects the old symbol.
Bart
Hi,
On 24-07-02, Bartosz Golaszewski wrote:
> On Mon, Jul 1, 2024 at 3:54 PM Marco Felsch wrote:
> >
> > All kernel users are shifted to the new MTD_EEPROM_AT24 Kconfig symbol
> > so we can drop the old one.
> >
>
> Nope, with this series arm64 still selects the old symbol.
sry. I must have for
David Hildenbrand writes:
> On 27.06.24 02:54, Alistair Popple wrote:
>> Currently DAX folio/page reference counts are managed differently to
>> normal pages. To allow these to be managed the same as normal pages
>> introduce dax_insert_pfn_pud. This will map the entire PUD-sized folio
>> and t
On 02.07.24 01:47, Alistair Popple wrote:
David Hildenbrand writes:
On 27.06.24 02:54, Alistair Popple wrote:
Longterm pinning of FS DAX pages should already be disallowed by
various pXX_devmap checks. However a future change will cause these
checks to be invalid for FS DAX pages so make
fol
David Hildenbrand writes:
> On 27.06.24 02:54, Alistair Popple wrote:
>> Currently to map a DAX page the DAX driver calls vmf_insert_pfn. This
>> creates a special devmap PTE entry for the pfn but does not take a
>> reference on the underlying struct page for the mapping. This is
>> because DAX
On 02.07.24 12:19, Alistair Popple wrote:
David Hildenbrand writes:
On 27.06.24 02:54, Alistair Popple wrote:
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be managed the same as normal pages
introduce dax_insert_pfn_pud. This will map t
On Mon, 01 Jul 2024 11:26:38 -0700, Nathan Chancellor wrote:
> bitfield.h is not explicitly included but it is required for FIELD_PREP
> to be expanded by the preprocessor. If it is not implicitly included,
> there will be a compiler error (as seen with ARCH=hexagon allmodconfig):
>
> sound/soc/
On Tue, Jul 02, 2024 at 09:18:31AM +0200, David Hildenbrand wrote:
> We have this comparably nasty vmf_insert_mixed() that FS dax abused to
> insert into !VM_MIXED VMAs. Is that abuse now stopping and are there maybe
> ways to get rid of vmf_insert_mixed()?
Unfortunately it is also used by a few
David Hildenbrand writes:
> On 02.07.24 12:19, Alistair Popple wrote:
>> David Hildenbrand writes:
>>
>>> On 27.06.24 02:54, Alistair Popple wrote:
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be managed the same as normal page
On Tue, Jul 02, 2024 at 08:19:01PM +1000, Alistair Popple wrote:
> > (B) As long as we have subpage mapcounts, this prevents vmemmap
> > optimizations [1]. Is that only used for device-dax for now and are
> > there no plans to make use of that for fs-dax?
>
> I don't have any plans to. Thi
On 02.07.24 13:46, Christoph Hellwig wrote:
On Tue, Jul 02, 2024 at 09:18:31AM +0200, David Hildenbrand wrote:
We have this comparably nasty vmf_insert_mixed() that FS dax abused to
insert into !VM_MIXED VMAs. Is that abuse now stopping and are there maybe
ways to get rid of vmf_insert_mixed()?
Krzysztof Kozlowski writes:
> On 30/05/2024 16:46, Esben Haabendal wrote:
>> With CONFIG_FSL_IFC now being user-visible, and thus changed from a select
>> to depends in CONFIG_MTD_NAND_FSL_IFC, the dependencies needs to be
>> selected in defconfigs.
>>
>> Signed-off-by: Esben Haabendal
>
> Anyon
arc allmodconfig gcc-13.2.0
arc allnoconfig gcc-13.2.0
arc allyesconfig gcc-13.2.0
arc defconfig gcc-13.2.0
arc randconfig-001-20240702 gcc-13.2.0
arc
nfig gcc-13.2.0
arc randconfig-001-20240702 gcc-13.2.0
arc randconfig-002-20240702 gcc-13.2.0
arm allmodconfig gcc-13.2.0
arm allnoconfig gcc-13.2.0
arm allyesconfig
kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
callback.
This patch adds a new struct kmsg_dump_detail, that will hold the
reason and description, and pass it to the dump() callback.
To avoid updating all kmsg_dump() call, it adds a kmsg_dump_desc()
function and a macro for b
On 02/07/2024 14:01, Michael Ellerman wrote:
> Krzysztof Kozlowski writes:
>> On 30/05/2024 16:46, Esben Haabendal wrote:
>>> With CONFIG_FSL_IFC now being user-visible, and thus changed from a select
>>> to depends in CONFIG_MTD_NAND_FSL_IFC, the dependencies needs to be
>>> selected in defconfig
On 02.07.24 13:30, Alistair Popple wrote:
David Hildenbrand writes:
On 02.07.24 12:19, Alistair Popple wrote:
David Hildenbrand writes:
On 27.06.24 02:54, Alistair Popple wrote:
Currently DAX folio/page reference counts are managed differently to
normal pages. To allow these to be manage
Christophe Leroy writes:
> On book3s/64, the only user of hugepd is hash in 4k mode.
>
> All other setups (hash-64, radix-4, radix-64) use leaf PMD/PUD.
>
> Rework hash-4k to use contiguous PMD and PUD instead.
>
> In that setup there are only two huge page sizes: 16M and 16G.
>
> 16M sits at PMD
Hello Simon,
On Fri, Jun 28, 2024 at 05:32:26PM +0100, Simon Horman wrote:
> On Mon, Jun 24, 2024 at 09:21:21AM -0700, Breno Leitao wrote:
> > @@ -530,6 +530,7 @@ static void caam_qi_shutdown(void *data)
> >
> > if (kill_fq(qidev, per_cpu(pcpu_qipriv.rsp_fq, i)))
> >
This series should have reached maturity for linux-next.
Version v7 is rebased on top of mm-unstable (9bb8753acdd8)
Also see https://github.com/linuxppc/issues/issues/483
Unlike most architectures, powerpc 8xx HW requires a two-level
pagetable topology for all page sizes. So a leaf PMD-contig ap
From: Michael Ellerman
The nohash HTW_IBM (Hardware Table Walk) code is unused since support
for A2 was removed in commit fb5a515704d7 ("powerpc: Remove platforms/
wsp and associated pieces") (2014).
The remaining supported CPUs use either no HTW (data_tlb_miss_bolted),
or the e6500 HTW (data_tl
From: Michael Ellerman
A reasonable chunk of nohash/tlb.c is 64-bit only code, split it out
into a separate file.
Signed-off-by: Michael Ellerman
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/Makefile | 2 +-
arch/powerpc/mm/nohash/tlb.c| 343 +--
From: Michael Ellerman
All 64-bit Book3E have E500=y, so drop the unneeded ifdefs.
Signed-off-by: Michael Ellerman
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/tlb_64e.c | 12
1 file changed, 12 deletions(-)
diff --git a/arch/powerpc/mm/nohash/tlb_64e.c b/arch/powe
From: Michael Ellerman
All 64-bit Book3E have MMU_FTR_TYPE_FSL_E, since A2 was removed, so
remove checks for it in 64-bit only code.
Signed-off-by: Michael Ellerman
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/setup_64.c | 6 +-
arch/powerpc/mm/nohash/tlb_64e.c | 97
From: Michael Ellerman
The 64e TLB miss handler patching is done in setup_mmu_htw(), and then
again immediately afterward in early_init_mmu_global(). Consolidate it
into a single location.
Signed-off-by: Michael Ellerman
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/tlb_64e.c | 3
From: Michael Ellerman
There are two possibilities for book3e_htw_mode, PPC_HTW_E6500 or
PPC_HTW_NONE.
The TLB miss handlers are patched to use, respectively:
- exc_[data|indstruction]_tlb_miss_e6500_book3e
- exc_[data|indstruction]_tlb_miss_bolted_book3e
Which means the default handlers ar
On powerpc 8xx, when a page is 8M size, the information is in the PMD
entry. So allow architectures to provide __pte_leaf_size() instead of
pte_leaf_size() and provide the PMD entry to that function.
When __pte_leaf_size() is not defined, define it as a pte_leaf_size()
so that architectures not in
On powerpc 8xx huge_ptep_get() will need to know whether the given
ptep is a PTE entry or a PMD entry. This cannot be known with the
PMD entry itself because there is no easy way to know it from the
content of the entry.
So huge_ptep_get() will need to know either the size of the page
or get the p
_PAGE_PSIZE macro is never used outside the place it is defined
and is used only on 8xx and e500.
Remove indirection, remove it and use its content directly.
Signed-off-by: Christophe Leroy
Reviewed-by: Oscar Salvador
---
v6: Removed the change to pte-40x.h to avoid conflict with the removal of
Building on 32 bits with pmd_leaf() not returning always false leads
to the following error:
CC arch/powerpc/mm/pgtable.o
arch/powerpc/mm/pgtable.c: In function '__find_linux_pte':
arch/powerpc/mm/pgtable.c:506:1: error: function may return address of local
variable [-Werror=return-local-a
In preparation of implementing huge pages on powerpc 8xx
without hugepd, enclose hugepd related code inside an
ifdef CONFIG_ARCH_HAS_HUGEPD
This also allows removing some stubs.
Signed-off-by: Christophe Leroy
Reviewed-by: Oscar Salvador
---
v3:
- Prepare huge_pte_alloc() for full standard topo
set_huge_pte_at() expects the size of the hugepage as an int, not the
psize which is the index of the page definition in table mmu_psize_defs[]
Fixes: 935d4f0c6dc8 ("mm: hugetlb: add huge page size param to
set_huge_pte_at()")
Signed-off-by: Christophe Leroy
Reviewed-by: Oscar Salvador
---
arc
In order to fit better with standard Linux page tables layout, add
support for 8M pages using contiguous PTE entries in a standard
page table. Page tables will then be populated with 1024 similar
entries and two PMD entries will point to that page table.
The PMD entries also get a flag to tell it
On 8xx, only the shift field is used in struct mmu_psize_def
Remove other fields and related macros.
Signed-off-by: Christophe Leroy
Reviewed-by: Oscar Salvador
---
arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/po
enc field is hidden behind BOOK3E_PAGESZ_XX macros, and when you look
closer you realise that this field is nothing else than the value of
shift minus ten.
So remove enc field and calculate tsize from shift field.
Also remove inc field which is unused.
Signed-off-by: Christophe Leroy
Reviewed-b
At the time being when CONFIG_PTE_64BIT is selected, PTE entries are
64 bits but PGD entries are still 32 bits.
In order to allow leaf PMD entries, switch the PGD to 64 bits entries.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/pgtable-types.h | 4
arch/powerpc/kernel/head
Use PTE page size bits to encode hugepage size with the following
format corresponding to the values expected in bits 52-55 in MAS1
register. Those bits are called TSIZE:
00014 Kbyte
001016 Kbyte
001164 Kbyte
0100256 Kbyte
01011 Mbyte
Don't pre-check write access on read-only pages on data TLB error.
Load the TLB anyway and take a DSI exception when it happens. This
avoids reading SPRN_ESR at every data TLB error exception.
Signed-off-by: Christophe Leroy
---
v5: New
---
arch/powerpc/kernel/head_85xx.S | 15 ---
Move r13 load after the call to FIND_PTE, and use r13 instead of
r10 for storing fault address. This will allow using r10 freely
in FIND_PTE in following patch to handle hugepage size.
Signed-off-by: Christophe Leroy
---
v5: New
---
arch/powerpc/kernel/head_85xx.S | 30 --
e500 supports many page sizes among which the following size are
implemented in the kernel at the time being: 4M, 16M, 64M, 256M, 1G.
On e500, TLB miss for hugepages is exclusively handled by SW even
on e6500 which has HW assistance for 4k pages, so there are no
constraints like on the 8xx.
On e5
On book3s/64, the only user of hugepd is hash in 4k mode.
All other setups (hash-64, radix-4, radix-64) use leaf PMD/PUD.
Rework hash-4k to use contiguous PMD and PUD instead.
In that setup there are only two huge page sizes: 16M and 16G.
16M sits at PMD level and 16G at PUD level.
pte_update
All targets have now opted out of CONFIG_ARCH_HAS_HUGEPD so
remove left over code.
Signed-off-by: Christophe Leroy
Acked-by: Oscar Salvador
---
v5: Fix a forgotten #endif which ended up in following patch
---
arch/powerpc/include/asm/hugetlb.h | 7 -
arch/powerpc/include/asm/page.h
powerpc was the only user of CONFIG_ARCH_HAS_HUGEPD and doesn't
use it anymore, so remove all related code.
Signed-off-by: Christophe Leroy
Acked-by: Oscar Salvador
---
v4: Rebased on v6.10-rc1
v7: Rebased on mm-unstable (9bb8753acdd8)
---
include/linux/hugetlb.h | 6 --
mm/Kconfig
On Tue, Jul 02, 2024 at 03:41:52PM GMT, Pratyush Yadav wrote:
> On Mon, Jul 01 2024, Tudor Ambarus wrote:
>
> > On 7/1/24 2:53 PM, Marco Felsch wrote:
> >> EEPROMs can become quite large nowadays (>=64K). Exposing such devices
> >> as single device isn't always sufficient. There may be partitions
On Tue, Jul 02, 2024 at 04:15:20PM GMT, Pratyush Yadav wrote:
> On Tue, Jul 02 2024, Maxime Ripard wrote:
>
> > On Tue, Jul 02, 2024 at 03:41:52PM GMT, Pratyush Yadav wrote:
> >> On Mon, Jul 01 2024, Tudor Ambarus wrote:
> >>
> >> > On 7/1/24 2:53 PM, Marco Felsch wrote:
> >> >> EEPROMs can becom
Christian,
On Sun, 30 Jun 2024 11:21:55 +0100,
Christian Zigotzky wrote:
>
> Hello,
>
> There is an issue with the identification of ATA drives with our
> P.A. Semi Nemo boards [1] after the
> commit "of/irq: Factor out parsing of interrupt-map parent
> phandle+args from of_irq_parse_raw()" [2]
The PPC64 specific MMIO setup open codes DT address functions rather
than using standard address parsing functions. The open-coded version
fails to handle any address translation and is not endian safe.
I haven't found any evidence of what platform used this. The only thing
that turned up was a PP
On Sun, 30 Jun 2024 11:21:55 +0100,
Christian Zigotzky wrote:
>
> Hello,
>
> There is an issue with the identification of ATA drives with our
> P.A. Semi Nemo boards [1] after the
> commit "of/irq: Factor out parsing of interrupt-map parent
> phandle+args from of_irq_parse_raw()" [2].
[snip]
M
On Mon, Jul 01 2024, Tudor Ambarus wrote:
> On 7/1/24 2:53 PM, Marco Felsch wrote:
>> EEPROMs can become quite large nowadays (>=64K). Exposing such devices
>> as single device isn't always sufficient. There may be partitions which
>> require different access permissions. Also write access always
On Tue, Jul 02 2024, Maxime Ripard wrote:
> On Tue, Jul 02, 2024 at 03:41:52PM GMT, Pratyush Yadav wrote:
>> On Mon, Jul 01 2024, Tudor Ambarus wrote:
>>
>> > On 7/1/24 2:53 PM, Marco Felsch wrote:
>> >> EEPROMs can become quite large nowadays (>=64K). Exposing such devices
>> >> as single device
Hello Marc,
Thank you for your reply.
On 02.07.24 17:19, Marc Zyngier wrote:
Christian,
On Sun, 30 Jun 2024 11:21:55 +0100,
Christian Zigotzky wrote:
Hello,
There is an issue with the identification of ATA drives with our
P.A. Semi Nemo boards [1] after the
commit "of/irq: Factor out parsin
On 2024-07-02 18:55, Christian Zigotzky wrote:
Hello Marc,
Thank you for your reply.
On 02.07.24 17:19, Marc Zyngier wrote:
Please provide the device tree for your platform. It isn't possible to
debug this without it, no matter how many pictures you provide. If it
doesn't exist in source form,
On Tue, Jul 02, 2024 at 02:26:04PM +0200, Jocelyn Falempe wrote:
> kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
> callback.
> This patch adds a new struct kmsg_dump_detail, that will hold the
> reason and description, and pass it to the dump() callback.
Thanks! I like this
On Tue, Jul 2, 2024 at 10:54 AM Marc Zyngier wrote:
>
> On Sun, 30 Jun 2024 11:21:55 +0100,
> Christian Zigotzky wrote:
> >
> > Hello,
> >
> > There is an issue with the identification of ATA drives with our
> > P.A. Semi Nemo boards [1] after the
> > commit "of/irq: Factor out parsing of interru
Replace open-coded parsing of "reg" property with
of_property_read_reg().
Signed-off-by: Rob Herring (Arm)
---
arch/powerpc/kexec/file_load_64.c | 31 ++-
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/kexec/file_load_64.c
b/arch/powerpc
On Tue, 02 Jul 2024 21:48:23 +0100,
Rob Herring wrote:
>
> On Tue, Jul 2, 2024 at 10:54 AM Marc Zyngier wrote:
> >
> > On Sun, 30 Jun 2024 11:21:55 +0100,
> > Christian Zigotzky wrote:
> > >
> > > Hello,
> > >
> > > There is an issue with the identification of ATA drives with our
> > > P.A. Sem
Hi all,
Today's linux-next merge of the powerpc tree got a conflict in:
arch/powerpc/mm/nohash/Makefile
between commit:
9e49846e4d65 ("powerpc/64e: split out nohash Book3E 64-bit code")
from the mm-unstable branch of the mm tree and commit:
732b32daef80 ("powerpc: Remove core support fo
On Mon, 2024-07-01 at 15:14 -0400, Stefan Berger wrote:
> Applying it is probably the better path forward than restricting HMAC to
> x86_64 now and enabling it on a per-architecture basis afterwards ...
Why is this here and not in the associated patch?
Any, what argue against is already done for
On Tue, 2024-07-02 at 10:10 -0600, Rob Herring (Arm) wrote:
> The PPC64 specific MMIO setup open codes DT address functions rather
> than using standard address parsing functions. The open-coded version
> fails to handle any address translation and is not endian safe.
>
> I haven't found any evide
On Wed, 2024-07-03 at 02:48 +0300, Jarkko Sakkinen wrote:
> On Mon, 2024-07-01 at 15:14 -0400, Stefan Berger wrote:
> > Applying it is probably the better path forward than restricting HMAC to
> > x86_64 now and enabling it on a per-architecture basis afterwards ...
>
> Why is this here and not i
On Mon, Jul 01, 2024 at 10:04:16AM +0530, Athira Rajeev wrote:
> Add TYPE_STATE_MAX_REGS_X86 and TYPE_STATE_MAX_REGS_PPC. Define
> TYPE_STATE_MAX_REGS to be 32 which is max size of the array. While
> checking if reg is valid using has_reg_type, use the max value
> depending on the architecture. For
On Wed Jul 3, 2024 at 2:57 AM EEST, Jarkko Sakkinen wrote:
> On Wed, 2024-07-03 at 02:48 +0300, Jarkko Sakkinen wrote:
> > On Mon, 2024-07-01 at 15:14 -0400, Stefan Berger wrote:
> > > Applying it is probably the better path forward than restricting HMAC to
> > > x86_64 now and enabling it on a pe
On Wed Jul 3, 2024 at 3:34 AM EEST, Jarkko Sakkinen wrote:
> https://lore.kernel.org/linux-integrity/20240703003033.19057-1-jar...@kernel.org/T/#u
>
> There's also bunch of other drivers than tpm_ibmvtpm so better
> to limit it to known good drivers.
>
> I can take at the actual issue in August and
On Wed Jul 3, 2024 at 3:48 AM EEST, Jarkko Sakkinen wrote:
> On Wed Jul 3, 2024 at 3:34 AM EEST, Jarkko Sakkinen wrote:
> > https://lore.kernel.org/linux-integrity/20240703003033.19057-1-jar...@kernel.org/T/#u
> >
> > There's also bunch of other drivers than tpm_ibmvtpm so better
> > to limit it to
On Mon, Jul 01, 2024 at 10:04:17AM +0530, Athira Rajeev wrote:
> Currently, the perf tool infrastructure disasm_line__parse function to
> parse disassembled line.
>
> Example snippet from objdump:
> objdump --start-address= --stop-address= -d
> --no-show-raw-insn -C
>
> c10224b4:
On Mon, Jul 01, 2024 at 10:04:18AM +0530, Athira Rajeev wrote:
> Add support to capture and parse raw instruction in powerpc.
> Currently, the perf tool infrastructure uses two ways to disassemble
> and understand the instruction. One is objdump and other option is
> via libcapstone.
>
> Currently
On Mon, Jul 01, 2024 at 10:04:28AM +0530, Athira Rajeev wrote:
> There are cases where define a global register variable and associate it
> with a specified register. Example, in powerpc, two registers are
> defined to represent variable:
> 1. r13: represents local_paca
> register struct paca_struc
On Mon, Jul 01, 2024 at 10:04:29AM +0530, Athira Rajeev wrote:
> In case of register defined variable (found using
> find_data_type_global_reg), if the type of variable happens to be base
> type (example, long unsigned int), perf report captures it as:
>
> 12.85% long unsigned int long unsig
Hello Marc,
On 02.07.24 21:49, Marc Zyngier wrote:
On 2024-07-02 18:55, Christian Zigotzky wrote:
Hello Marc,
Thank you for your reply.
On 02.07.24 17:19, Marc Zyngier wrote:
Please provide the device tree for your platform. It isn't possible to
debug this without it, no matter how many pict
Hello Marc,
On 02.07.24 18:54, Marc Zyngier wrote:
On Sun, 30 Jun 2024 11:21:55 +0100,
Christian Zigotzky wrote:
Hello,
There is an issue with the identification of ATA drives with our
P.A. Semi Nemo boards [1] after the
commit "of/irq: Factor out parsing of interrupt-map parent
phandle+args
On Wed, 03 Jul 2024 04:11:55 +0100,
Christian Zigotzky wrote:
>
> Hello Marc,
>
> On 02.07.24 21:49, Marc Zyngier wrote:
> > On 2024-07-02 18:55, Christian Zigotzky wrote:
> >> Hello Marc,
> >>
> >> Thank you for your reply.
> >>
> >> On 02.07.24 17:19, Marc Zyngier wrote:
> >>> Please provide
On Wed, 03 Jul 2024 04:27:37 +0100,
Christian Zigotzky wrote:
>
> Hello Marc,
>
> On 02.07.24 18:54, Marc Zyngier wrote:
> > On Sun, 30 Jun 2024 11:21:55 +0100,
> > Christian Zigotzky wrote:
> >> Hello,
> >>
> >> There is an issue with the identification of ATA drives with our
> >> P.A. Semi N
78 matches
Mail list logo
