Re: [PATCH v2] powerpc: allow PPC_EARLY_DEBUG_CPM only when SERIAL_CPM=y
Le 01/07/2023 à 07:47, Randy Dunlap a écrit :
> In a randconfig with CONFIG_SERIAL_CPM=m and
> CONFIG_PPC_EARLY_DEBUG_CPM=y, there is a build error:
> ERROR: modpost: "udbg_putc" [drivers/tty/serial/cpm_uart/cpm_uart.ko]
> undefined!
>
> Prevent the build error by allowing PPC_EARLY_DEBUG_CPM only when
> SERIAL_CPM=y.
>
> Fixes: c374e00e17f1 ("[POWERPC] Add early debug console for CPM serial
> ports.")
> Signed-off-by: Randy Dunlap
> Cc: Kumar Gala
> Cc: "Pali Rohár"
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> Cc: linuxppc-dev@lists.ozlabs.org
> Reviewed-by: Pali Rohár
Reviewed-by: Christophe Leroy
> ---
> v2: add Pali's R-b;
> drop Scott Wood from Cc: list
>
> arch/powerpc/Kconfig.debug |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -- a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
> --- a/arch/powerpc/Kconfig.debug
> +++ b/arch/powerpc/Kconfig.debug
> @@ -240,7 +240,7 @@ config PPC_EARLY_DEBUG_40x
>
> config PPC_EARLY_DEBUG_CPM
> bool "Early serial debugging for Freescale CPM-based serial ports"
> - depends on SERIAL_CPM
> + depends on SERIAL_CPM=y
> help
> Select this to enable early debugging for Freescale chips
> using a CPM-based serial port. This assumes that the bootwrapper
Re: [PATCH] powerpc: allow PPC_EARLY_DEBUG_CPM only when SERIAL_CPM=y
Le 01/07/2023 à 07:46, Randy Dunlap a écrit :
>
>
> On 6/9/23 20:11, Randy Dunlap wrote:
>> Hi--
>>
>> On 5/16/23 11:54, Pali Rohár wrote:
>>> On Tuesday 16 May 2023 08:28:54 Randy Dunlap wrote:
In a randconfig with CONFIG_SERIAL_CPM=m and
CONFIG_PPC_EARLY_DEBUG_CPM=y, there is a build error:
ERROR: modpost: "udbg_putc" [drivers/tty/serial/cpm_uart/cpm_uart.ko]
undefined!
Prevent the build error by allowing PPC_EARLY_DEBUG_CPM only when
SERIAL_CPM=y.
Fixes: c374e00e17f1 ("[POWERPC] Add early debug console for CPM serial
ports.")
Signed-off-by: Randy Dunlap
Cc: Scott Wood
Cc: Kumar Gala
Cc: "Pali Rohár"
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: linuxppc-dev@lists.ozlabs.org
>>>
>>> Looks good,
>>>
>>> Reviewed-by: Pali Rohár
>>
>> I'm still seeing this build error in linux-next even with other (PPC) CPM
>> patches applied.
>>
>
> Patchwork shows status as Superseded:
>
> http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20230516152854.22465-1-rdun...@infradead.org/
>
> but I don't understand why or by what.
Neither do I. I must have made a mistake but I can't remember.
>
> I'm going to resubmit the patch now.
Fine, then the previous is really superseeded now.
Christophe
>
>
>>>
---
arch/powerpc/Kconfig.debug |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -- a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -240,7 +240,7 @@ config PPC_EARLY_DEBUG_40x
config PPC_EARLY_DEBUG_CPM
bool "Early serial debugging for Freescale CPM-based serial ports"
- depends on SERIAL_CPM
+ depends on SERIAL_CPM=y
help
Select this to enable early debugging for Freescale chips
using a CPM-based serial port. This assumes that the bootwrapper
>>
>
[PATCH v2] powerpc: allow PPC_EARLY_DEBUG_CPM only when SERIAL_CPM=y
In a randconfig with CONFIG_SERIAL_CPM=m and
CONFIG_PPC_EARLY_DEBUG_CPM=y, there is a build error:
ERROR: modpost: "udbg_putc" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined!
Prevent the build error by allowing PPC_EARLY_DEBUG_CPM only when
SERIAL_CPM=y.
Fixes: c374e00e17f1 ("[POWERPC] Add early debug console for CPM serial ports.")
Signed-off-by: Randy Dunlap
Cc: Kumar Gala
Cc: "Pali Rohár"
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: linuxppc-dev@lists.ozlabs.org
Reviewed-by: Pali Rohár
---
v2: add Pali's R-b;
drop Scott Wood from Cc: list
arch/powerpc/Kconfig.debug |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -- a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -240,7 +240,7 @@ config PPC_EARLY_DEBUG_40x
config PPC_EARLY_DEBUG_CPM
bool "Early serial debugging for Freescale CPM-based serial ports"
- depends on SERIAL_CPM
+ depends on SERIAL_CPM=y
help
Select this to enable early debugging for Freescale chips
using a CPM-based serial port. This assumes that the bootwrapper
Re: [PATCH] powerpc: allow PPC_EARLY_DEBUG_CPM only when SERIAL_CPM=y
On 6/9/23 20:11, Randy Dunlap wrote:
> Hi--
>
> On 5/16/23 11:54, Pali Rohár wrote:
>> On Tuesday 16 May 2023 08:28:54 Randy Dunlap wrote:
>>> In a randconfig with CONFIG_SERIAL_CPM=m and
>>> CONFIG_PPC_EARLY_DEBUG_CPM=y, there is a build error:
>>> ERROR: modpost: "udbg_putc" [drivers/tty/serial/cpm_uart/cpm_uart.ko]
>>> undefined!
>>>
>>> Prevent the build error by allowing PPC_EARLY_DEBUG_CPM only when
>>> SERIAL_CPM=y.
>>>
>>> Fixes: c374e00e17f1 ("[POWERPC] Add early debug console for CPM serial
>>> ports.")
>>> Signed-off-by: Randy Dunlap
>>> Cc: Scott Wood
>>> Cc: Kumar Gala
>>> Cc: "Pali Rohár"
>>> Cc: Michael Ellerman
>>> Cc: Nicholas Piggin
>>> Cc: Christophe Leroy
>>> Cc: linuxppc-dev@lists.ozlabs.org
>>
>> Looks good,
>>
>> Reviewed-by: Pali Rohár
>
> I'm still seeing this build error in linux-next even with other (PPC) CPM
> patches applied.
>
Patchwork shows status as Superseded:
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20230516152854.22465-1-rdun...@infradead.org/
but I don't understand why or by what.
I'm going to resubmit the patch now.
>>
>>> ---
>>> arch/powerpc/Kconfig.debug |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff -- a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
>>> --- a/arch/powerpc/Kconfig.debug
>>> +++ b/arch/powerpc/Kconfig.debug
>>> @@ -240,7 +240,7 @@ config PPC_EARLY_DEBUG_40x
>>>
>>> config PPC_EARLY_DEBUG_CPM
>>> bool "Early serial debugging for Freescale CPM-based serial ports"
>>> - depends on SERIAL_CPM
>>> + depends on SERIAL_CPM=y
>>> help
>>> Select this to enable early debugging for Freescale chips
>>> using a CPM-based serial port. This assumes that the bootwrapper
>
--
~Randy
[PATCH v2 RESEND RESEND] ASoC: fsl MPC52xx drivers require PPC_BESTCOMM
Both SND_MPC52xx_SOC_PCM030 and SND_MPC52xx_SOC_EFIKA select
SND_SOC_MPC5200_AC97. The latter symbol depends on PPC_BESTCOMM,
so the 2 former symbols should also depend on PPC_BESTCOMM since
"select" does not follow any dependency chains.
This prevents a kconfig warning and build errors:
WARNING: unmet direct dependencies detected for SND_SOC_MPC5200_AC97
Depends on [n]: SOUND [=y] && !UML && SND [=m] && SND_SOC [=m] &&
SND_POWERPC_SOC [=m] && PPC_MPC52xx [=y] && PPC_BESTCOMM [=n]
Selected by [m]:
- SND_MPC52xx_SOC_PCM030 [=m] && SOUND [=y] && !UML && SND [=m] && SND_SOC
[=m] && SND_POWERPC_SOC [=m] && PPC_MPC5200_SIMPLE [=y]
- SND_MPC52xx_SOC_EFIKA [=m] && SOUND [=y] && !UML && SND [=m] && SND_SOC
[=m] && SND_POWERPC_SOC [=m] && PPC_EFIKA [=y]
ERROR: modpost: "mpc5200_audio_dma_destroy" [sound/soc/fsl/mpc5200_psc_ac97.ko]
undefined!
ERROR: modpost: "mpc5200_audio_dma_create" [sound/soc/fsl/mpc5200_psc_ac97.ko]
undefined!
Fixes: 40d9ec14e7e1 ("ASoC: remove BROKEN from Efika and pcm030 fabric drivers")
Signed-off-by: Randy Dunlap
Cc: Grant Likely
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Shengjiu Wang
Cc: Xiubo Li
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Acked-by: Shengjiu Wang
---
v2: use correct email address for Mark Brown.
sound/soc/fsl/Kconfig |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -- a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -243,7 +243,7 @@ config SND_SOC_MPC5200_AC97
config SND_MPC52xx_SOC_PCM030
tristate "SoC AC97 Audio support for Phytec pcm030 and WM9712"
- depends on PPC_MPC5200_SIMPLE
+ depends on PPC_MPC5200_SIMPLE && PPC_BESTCOMM
select SND_SOC_MPC5200_AC97
select SND_SOC_WM9712
help
@@ -252,7 +252,7 @@ config SND_MPC52xx_SOC_PCM030
config SND_MPC52xx_SOC_EFIKA
tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
- depends on PPC_EFIKA
+ depends on PPC_EFIKA && PPC_BESTCOMM
select SND_SOC_MPC5200_AC97
select SND_SOC_STAC9766
help
Re: [PATCH 00/79] fs: new accessors for inode->i_ctime
On Wed, Jun 21, 2023 at 03:21:41PM -0400, Steven Rostedt wrote: > On Wed, 21 Jun 2023 10:45:05 -0400 > Jeff Layton wrote: > > > Most of this conversion was done via coccinelle, with a few of the more > > non-standard accesses done by hand. There should be no behavioral > > changes with this set. That will come later, as we convert individual > > filesystems to use multigrain timestamps. > > BTW, Linus has suggested to me that whenever a conccinelle script is used, > it should be included in the change log. Sometimes people like the coccinelle included in the commit, sometimes people don't [0], it really ends up being up to a subjective maintainer preference. A compromise could be to use git notes as these are optional, however if we want to go down that path we should try to make a general consensus on it so we can send a consistent message. [0] https://lore.kernel.org/all/20230512073100.gc32...@twin.jikos.cz/ Luis
Re: [PATCH 01/79] fs: add ctime accessors infrastructure
On Wed, Jun 21, 2023 at 10:45:06AM -0400, Jeff Layton wrote: > struct timespec64 has unused bits in the tv_nsec field that can be used > for other purposes. In future patches, we're going to change how the > inode->i_ctime is accessed in certain inodes in order to make use of > them. In order to do that safely though, we'll need to eradicate raw > accesses of the inode->i_ctime field from the kernel. > > Add new accessor functions for the ctime that we can use to replace them. > > Signed-off-by: Jeff Layton Reviewed-by: Luis Chamberlain Luis
Re: [FSL P50x0] [PASEMI] The Access to partitions on disks with an Amiga partition table doesn't work anymore after the block updates 2023-06-23
Hi Martin, Christian, Am 01.07.2023 um 09:17 schrieb Michael Schmitz: By reverting my patch, you just reintroduce the old bug, which could result in mis-parsing the partition table in a way that is not detected by inane values of partition sizes as above, and as far as I recall this bug was reported because it did cause data corruption. Do I have that correct, Martin? Do you still have a copy of the problematic RDB from the old bug report around? It is in the first attachment of the bug report I mentioned above. The bug the patch fixed. Thanks, I'll get it from there. Confirmed the bug on that RDB block, also that my proposed patch fixes it, at least as far as that's possible to show with a sparse image file. Now I note that this patch will actually treat any partition block address beyond the 31 bit limit as end of the linked list, but that's been the behaviour of Linux RDB partitions since very early on, so I see no reason to change that. The RDB format description URL that appears in one of your messages from the 2012 thread has gone dead. I'll try to find it on Wayback later. In the meantime, I will submit a patch to fix the new bug ... We can has out details in the inevitable review process. Cheers, Michael
[PATCH v8 12/14] PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler
From: Robert Richter
In Restricted CXL Device (RCD) mode a CXL device is exposed as an
RCiEP, but CXL downstream and upstream ports are not enumerated and
not visible in the PCIe hierarchy. [1] Protocol and link errors from
these non-enumerated ports are signaled as internal AER errors, either
Uncorrectable Internal Error (UIE) or Corrected Internal Errors (CIE)
via an RCEC.
Restricted CXL host (RCH) downstream port-detected errors have the
Requester ID of the RCEC set in the RCEC's AER Error Source ID
register. A CXL handler must then inspect the error status in various
CXL registers residing in the dport's component register space (CXL
RAS capability) or the dport's RCRB (PCIe AER extended
capability). [2]
Errors showing up in the RCEC's error handler must be handled and
connected to the CXL subsystem. Implement this by forwarding the error
to all CXL devices below the RCEC. Since the entire CXL device is
controlled only using PCIe Configuration Space of device 0, function
0, only pass it there [3]. The error handling is limited to currently
supported devices with the Memory Device class code set (CXL Type 3
Device, PCI_CLASS_MEMORY_CXL, 502h), handle downstream port errors in
the device's cxl_pci driver. Support for other CXL Device Types
(e.g. a CXL.cache Device) can be added later.
To handle downstream port errors in addition to errors directed to the
CXL endpoint device, a handler must also inspect the CXL RAS and PCIe
AER capabilities of the CXL downstream port the device is connected
to.
Since CXL downstream port errors are signaled using internal errors,
the handler requires those errors to be unmasked. This is subject of a
follow-on patch.
The reason for choosing this implementation is that the AER service
driver claims the RCEC device, but does not allow it to register a
custom specific handler to support CXL. Connecting the RCEC hard-wired
with a CXL handler does not work, as the CXL subsystem might not be
present all the time. The alternative to add an implementation to the
portdrv to allow the registration of a custom RCEC error handler isn't
worth doing it as CXL would be its only user. Instead, just check for
an CXL RCEC and pass it down to the connected CXL device's error
handler. With this approach the code can entirely be implemented in
the PCIe AER driver and is independent of the CXL subsystem. The CXL
driver only provides the handler.
[1] CXL 3.0 spec: 9.11.8 CXL Devices Attached to an RCH
[2] CXL 3.0 spec, 12.2.1.1 RCH Downstream Port-detected Errors
[3] CXL 3.0 spec, 8.1.3 PCIe DVSEC for CXL Devices
Co-developed-by: Terry Bowman
Signed-off-by: Terry Bowman
Signed-off-by: Robert Richter
Cc: "Oliver O'Halloran"
Cc: Bjorn Helgaas
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Acked-by: Bjorn Helgaas
Reviewed-by: Jonathan Cameron
Reviewed-by: Dave Jiang
---
drivers/pci/pcie/Kconfig | 12 +
drivers/pci/pcie/aer.c | 96 +++-
2 files changed, 106 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
index 228652a59f27..4f0e70fafe2d 100644
--- a/drivers/pci/pcie/Kconfig
+++ b/drivers/pci/pcie/Kconfig
@@ -49,6 +49,18 @@ config PCIEAER_INJECT
gotten from:
https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/
+config PCIEAER_CXL
+ bool "PCI Express CXL RAS support for Restricted Hosts (RCH)"
+ default y
+ depends on PCIEAER && CXL_PCI
+ help
+ Enables error handling of downstream ports of a CXL host
+ that is operating in RCD mode (Restricted CXL Host, RCH).
+ The downstream port reports AER errors to a given RCEC.
+ Errors are handled by the CXL memory device driver.
+
+ If unsure, say Y.
+
#
# PCI Express ECRC
#
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index d3344fcf1f79..c354ca5e8f2b 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -946,14 +946,100 @@ static bool find_source_device(struct pci_dev *parent,
return true;
}
+#ifdef CONFIG_PCIEAER_CXL
+
+static bool is_cxl_mem_dev(struct pci_dev *dev)
+{
+ /*
+* The capability, status, and control fields in Device 0,
+* Function 0 DVSEC control the CXL functionality of the
+* entire device (CXL 3.0, 8.1.3).
+*/
+ if (dev->devfn != PCI_DEVFN(0, 0))
+ return false;
+
+ /*
+* CXL Memory Devices must have the 502h class code set (CXL
+* 3.0, 8.1.12.1).
+*/
+ if ((dev->class >> 8) != PCI_CLASS_MEMORY_CXL)
+ return false;
+
+ return true;
+}
+
+static bool cxl_error_is_native(struct pci_dev *dev)
+{
+ struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
+
+ if (pcie_ports_native)
+ return true;
+
+ return host->native_aer && host->native_cxl_error;
+}
+
+static bool is_internal_error(struct aer_err_info *info)
+{
+ if
Re: [PATCH v3 12/13] s390/kexec: refactor for kernel/Kconfig.kexec
On 6/30/23 08:07, Alexander Gordeev wrote:
On Mon, Jun 26, 2023 at 12:13:31PM -0400, Eric DeVolder wrote:
The kexec and crash kernel options are provided in the common
kernel/Kconfig.kexec. Utilize the common options and provide
the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
equivalent set of KEXEC and CRASH options.
NOTE: The original Kconfig has a KEXEC_SIG which depends on
MODULE_SIG_FORMAT. However, attempts to keep the MODULE_SIG_FORMAT
dependency (using the strategy outlined in this series, and other
techniques) results in 'error: recursive dependency detected'
on CRYPTO.
Per Alexander Gordeev : "the MODULE_SIG_FORMAT
dependency was introduced with [git commit below] and in fact was not
necessary, since s390 did/does not use mod_check_sig() anyway.
commit c8424e776b09 ("MODSIGN: Export module signature definitions")
MODULE_SIG_FORMAT is needed to select SYSTEM_DATA_VERIFICATION. But
SYSTEM_DATA_VERIFICATION is also selected by FS_VERITY*, so dropping
MODULE_SIG_FORMAT does not hurt."
Therefore, the solution is to drop the MODULE_SIG_FORMAT dependency
from KEXEC_SIG. Still results in equivalent .config files for s390.
Signed-off-by: Eric DeVolder
---
arch/s390/Kconfig | 65 ++-
1 file changed, 19 insertions(+), 46 deletions(-)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 6dab9c1be508..58dc124433ca 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -243,6 +243,25 @@ config PGTABLE_LEVELS
source "kernel/livepatch/Kconfig"
+config ARCH_DEFAULT_KEXEC
+ def_bool y
+
+config ARCH_SUPPORTS_KEXEC
+ def_bool y
+
+config ARCH_SUPPORTS_KEXEC_FILE
+ def_bool CRYPTO && CRYPTO_SHA256 && CRYPTO_SHA256_S390
+
+config ARCH_HAS_KEXEC_PURGATORY
+ def_bool KEXEC_FILE
+
+config ARCH_SUPPORTS_CRASH_DUMP
+ def_bool y
+ help
+ Refer to for more details on
this.
+ This option also enables s390 zfcpdump.
+ See also
+
menu "Processor type and features"
config HAVE_MARCH_Z10_FEATURES
@@ -481,36 +500,6 @@ config SCHED_TOPOLOGY
source "kernel/Kconfig.hz"
-config KEXEC
- def_bool y
- select KEXEC_CORE
-
-config KEXEC_FILE
- bool "kexec file based system call"
- select KEXEC_CORE
- depends on CRYPTO
- depends on CRYPTO_SHA256
- depends on CRYPTO_SHA256_S390
- help
- Enable the kexec file based system call. In contrast to the normal
- kexec system call this system call takes file descriptors for the
- kernel and initramfs as arguments.
-
-config ARCH_HAS_KEXEC_PURGATORY
- def_bool y
- depends on KEXEC_FILE
-
-config KEXEC_SIG
- bool "Verify kernel signature during kexec_file_load() syscall"
- depends on KEXEC_FILE && MODULE_SIG_FORMAT
- help
- This option makes kernel signature verification mandatory for
- the kexec_file_load() syscall.
-
- In addition to that option, you need to enable signature
- verification for the corresponding kernel image type being
- loaded in order for this to work.
-
config KERNEL_NOBP
def_bool n
prompt "Enable modified branch prediction for the kernel by default"
@@ -732,22 +721,6 @@ config VFIO_AP
endmenu
-menu "Dump support"
-
-config CRASH_DUMP
- bool "kernel crash dumps"
- select KEXEC
- help
- Generate crash dump after being started by kexec.
- Crash dump kernels are loaded in the main kernel with kexec-tools
- into a specially reserved region and then later executed after
- a crash by kdump/kexec.
- Refer to for more details on
this.
- This option also enables s390 zfcpdump.
- See also
-
-endmenu
-
config CCW
def_bool y
Acked-by: Alexander Gordeev
Thank you Alexander!
eric
Re: [FSL P50x0] [PASEMI] The Access to partitions on disks with an Amiga partition table doesn't work anymore after the block updates 2023-06-23
Hi Martin,
Am 30.06.2023 um 20:35 schrieb Martin Steigerwald:
Hi Michael, hi Christian.
Michael Schmitz - 29.06.23, 22:27:59 CEST:
[…]
On 29/06/23 16:59, Christian Zigotzky wrote:
Hello,
The access to partitions on disks with an Amiga partition table
(via the Rigid Disk Block RDB) doesn't work anymore on my Cyrus+
board with a FSL P50x0 PowerPC SoC [1] and on my P.A. Semi Nemo
board [2] after the block updates 2023-06-23 [3].
parted -l
[…]
dmesg | grep -i sda
[4.208905] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks:
(2.00 TB/1.82 TiB)
That is roughly the size of the disk that triggered my bug report from
2012.
Jun 19 21:19:09 merkaba kernel: [ 7891.821315] ata8.00: 3907029168
sectors, multi 0: LBA48 NCQ (depth 31/32)
Bug 43511 - Partitions: Amiga RDB partition on 2 TB disk way too big,
while OK in AmigaOS 4.1
https://bugzilla.kernel.org/show_bug.cgi?id=43511
Yes, that's been the first disk size allowing the overflow to occur.
This time it's not about partition size but partition block address though.
By reverting my patch, you just reintroduce the old bug, which could
result in mis-parsing the partition table in a way that is not
detected by inane values of partition sizes as above, and as far as I
recall this bug was reported because it did cause data corruption. Do
I have that correct, Martin? Do you still have a copy of the
problematic RDB from the old bug report around?
It is in the first attachment of the bug report I mentioned above. The
bug the patch fixed.
Thanks, I'll get it from there.
In the bug report I wrote:
"I had a BTRFS filesystem that had some checksum errors. Maybe thats
somehow related to this issue and AmigaOS and/or Linux overwrote
something it shouldn´t have touched."
(Meanwhile I bet it is safe to assume that in case the checksum error
was from overwriting something it was not AmigaOS 4.)
This is no proof, but as I re-read my bug report: It is clearly an
overflow issue worsened by Linux back then truncating the too high
partition sizes larger than the disk to the disk size instead of bailing
out. So the partition I created for the Linux LVM in front of the Amiga
partitions overflowed into the Amiga partitions. Had I used that place
inside the PV for any LV and written to it… I bet it would have been
goodbye to the Amiga data.
Thanks, that's good enough reason for me to not back out patch 3.
Could you please check your commit?
The patch series has undergone the usual thirteen versions in review,
but the reviewers as well as myself may well have missed this point of
detail...
I think the patch series has been very well reviewed, but I would not
have spotted such an issue as I am not really an RDB expert and even
I agree - not meant as a slight to the reviewers but more a dig at my
patch record.
then, with all the big endian conversions and what not inside of there…
In my understanding the RDB format is not really as Rigid as the name
implies. It is quite flexible, especially when compared to what had been
used on PC back then and sometimes even now. So there is a chance for a
RDB partitioning that triggers an oversight in the patch series.
At least it did show up in testing real fast.
Could you please check this (whitespace-damaged) patch?
block/partitions - Amiga partition overflow fix bugfix
Making 'blk' sector_t (i.e. 64 bit if LBD support is active)
fails the 'blk>0' test in the partition block loop if a
value of (signed int) -1 is used to mark the end of the
partition block list.
Explicitly cast 'blk' to signed int to catch this.
Signed-off-by: Michael Schmitz
diff --git a/block/partitions/amiga.c b/block/partitions/amiga.c
index ed222b9c901b..506921095412 100644
--- a/block/partitions/amiga.c
+++ b/block/partitions/amiga.c
@@ -90,7 +90,7 @@ int amiga_partition(struct parsed_partitions *state)
}
blk = be32_to_cpu(rdb->rdb_PartitionList);
put_dev_sector(sect);
- for (part = 1; blk>0 && part<=16; part++,
put_dev_sector(sect)) {
+ for (part = 1; (s32) blk>0 && part<=16; part++,
put_dev_sector(sect)) {
Makes sense to me.
Good, now we just need to see whether it does indeed fix the issue.
Cheers,
Michael
Re: [PATCH] cpufreq: pmac32: Use of_property_read_reg() to parse "reg"
On Fri, Jun 9, 2023 at 12:31 PM Rob Herring wrote:
>
> Use the recently added of_property_read_reg() helper to get the
> untranslated "reg" address value.
>
> Signed-off-by: Rob Herring
> ---
> drivers/cpufreq/pmac32-cpufreq.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Ping!
>
> diff --git a/drivers/cpufreq/pmac32-cpufreq.c
> b/drivers/cpufreq/pmac32-cpufreq.c
> index ec75e79659ac..f53635ba16c1 100644
> --- a/drivers/cpufreq/pmac32-cpufreq.c
> +++ b/drivers/cpufreq/pmac32-cpufreq.c
> @@ -378,10 +378,9 @@ static int pmac_cpufreq_cpu_init(struct cpufreq_policy
> *policy)
>
> static u32 read_gpio(struct device_node *np)
> {
> - const u32 *reg = of_get_property(np, "reg", NULL);
> - u32 offset;
> + u64 offset;
>
> - if (reg == NULL)
> + if (of_property_read_reg(np, 0, &offset, NULL) < 0)
> return 0;
> /* That works for all keylargos but shall be fixed properly
> * some day... The problem is that it seems we can't rely
> --
> 2.39.2
>
Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page
On Fri, 30 Jun 2023, Claudio Imbrenda wrote:
> On Fri, 30 Jun 2023 08:28:54 -0700 (PDT)
> Hugh Dickins wrote:
> > On Fri, 30 Jun 2023, Claudio Imbrenda wrote:
> > > On Tue, 20 Jun 2023 00:51:19 -0700 (PDT)
> > > Hugh Dickins wrote:
> > >
> > > [...]
> > >
> > > > +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable)
> > > > +{
> > > > + unsigned int bit, mask;
> > > > + struct page *page;
> > > > +
> > > > + page = virt_to_page(pgtable);
> > > > + if (mm_alloc_pgste(mm)) {
> > > > + call_rcu(&page->rcu_head, pte_free_pgste);
> > >
> > > so is this now going to be used to free page tables
> > > instead of page_table_free_rcu?
> >
> > No.
> >
> > All pte_free_defer() is being used for (in this series; and any future
> > use beyond this series will have to undertake its own evaluations) is
> > for the case of removing an empty page table, which used to map a group
> > of PTE mappings of a file, in order to make way for one PMD mapping of
> > the huge page which those scattered pages have now been gathered into.
> >
> > You're worried by that mm_alloc_pgste() block: it's something I didn't
>
> actually no, but thanks for bringing it up :D
>
> > have at all in my first draft, then I thought that perhaps the pgste
> > case might be able to come this way, so it seemed stupid to leave out
> > the handling for it.
> >
> > I hope that you're implying that should be dead code here? Perhaps,
> > that the pgste case corresponds to the case in s390 where THPs are
> > absolutely forbidden? That would be good news for us.
> >
> > Gerald, in his version of this block, added a comment asking:
> > /*
> > * TODO: Do we need gmap_unlink(mm, pgtable, addr), like in
> > * page_table_free_rcu()?
> > * If yes -> need addr parameter here, like in pte_free_tlb().
> > */
> > Do you have the answer to that? Neither of us could work it out.
>
> this is the thing I'm worried about; removing a page table that was
> used to map a guest will leave dangling pointers in the gmap that will
> cause memory corruption (I actually ran into that problem myself for
> another patchseries).
>
> gmap_unlink() is needed to clean up the pointers before they become
> dangling (and also potentially do some TLB purging as needed)
That's something I would have expected to be handled already via
mmu_notifiers, rather than buried inside the page table freeing.
If s390 is the only architecture to go that way, and could instead do
it via mmu_notifiers, then I think that will be more easily supported
in the long term.
But I'm writing from a position of very great ignorance: advising
KVM on s390 is many dimensions away from what I'm capable of.
>
> the point here is: we need that only for page_table_free_rcu(); all
> other users of page_table_free() cannot act on guest page tables
I might be wrong, but I think that most users of page_table_free()
are merely freeing a page table which had to be allocated up front,
but was then found unnecessary (maybe a racing task already inserted
one): page tables which were never exposed to actual use.
> (because we don't allow THP for KVM guests). and that is why
> page_table_free() does not do gmap_unlink() currently.
But THP collapse does (or did before this series) use it to free a
page table which had been exposed to use. The fact that s390 does
not allow THP for KVM guests makes page_table_free(), and this new
pte_free_defer(), safe for that; but it feels dangerously coincidental.
It's easy to imagine a future change being made, which would stumble
over this issue. I have imagined that pte_free_defer() will be useful
in future, in the freeing of empty page tables: but s390 may pose a
problem there - though perhaps no more of a problem than additionally
needing to pass a virtual address down the stack.
>
> >
> > >
> > > or will it be used instead of page_table_free?
> >
> > Not always; but yes, this case of removing a page table used
> > page_table_free() before; but now, with the lighter locking, needs
> > to keep the page table valid until the RCU grace period expires.
>
> so if I understand correctly your code will, sometimes, under some
> circumstances, replace what page_table_free() does, but it will never
> replace page_table_free_rcu()?
>
> because in that case there would be no issues
Yes, thanks for confirming: we have no issue here at present, but may
do if use of pte_free_defer() is extended to other contexts in future.
Would it be appropriate to add a WARN_ON_ONCE around that
> > > > + if (mm_alloc_pgste(mm)) {
in pte_free_defer()?
I ask that somewhat rhetorically: that block disappears in the later
version I was working on last night (and will return to shortly), in
which pte_free_defer() just sets a bit and calls page_table_free().
But I'd like to understand the possibilities better: does mm_alloc_pgste()
correspond 1:1 to KVM guest on s390, or does it cover several different
possibiliti
Re: [PATCH v4 29/33] x86/mm: try VMA lock-based page fault handling first
On Fri, Jun 30, 2023 at 1:43 AM Jiri Slaby wrote:
>
> On 30. 06. 23, 10:28, Jiri Slaby wrote:
> > > 2348
> > clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
> > child_tid=0x7fcaa5882990, parent_tid=0x7fcaa5882990, exit_signal=0,
> > stack=0x7fcaa5082000, stack_size=0x7ffe00, tls=0x7fcaa58826c0} =>
> > {parent_tid=[2351]}, 88) = 2351
> > > 2350 <... clone3 resumed> => {parent_tid=[2372]}, 88) = 2372
> > > 2351 <... clone3 resumed> => {parent_tid=[2354]}, 88) = 2354
> > > 2351 <... clone3 resumed> => {parent_tid=[2357]}, 88) = 2357
> > > 2354 <... clone3 resumed> => {parent_tid=[2355]}, 88) = 2355
> > > 2355 <... clone3 resumed> => {parent_tid=[2370]}, 88) = 2370
> > > 2370 mmap(NULL, 262144, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0
> > > 2370 <... mmap resumed>) = 0x7fca68249000
> > > 2372 <... clone3 resumed> => {parent_tid=[2384]}, 88) = 2384
> > > 2384 <... clone3 resumed> => {parent_tid=[2388]}, 88) = 2388
> > > 2388 <... clone3 resumed> => {parent_tid=[2392]}, 88) = 2392
> > > 2392 <... clone3 resumed> => {parent_tid=[2395]}, 88) = 2395
> > > 2395 write(2, "runtime: marked free object in s"..., 36 > ...>
> >
> > I.e. IIUC, all are threads (CLONE_VM) and thread 2370 mapped ANON
> > 0x7fca68249000 - 0x7fca6827 and go in thread 2395 thinks for some
> > reason 0x7fca6824bec8 in that region is "bad".
Thanks for the analysis Jiri.
Is it possible from these logs to identify whether 2370 finished the
mmap operation before 2395 tried to access 0x7fca6824bec8? That access
has to happen only after mmap finishes mapping the region.
>
> As I was noticed, this might be as well be a fail of the go's
> inter-thread communication (or alike) too. It might now be only more
> exposed with vma-based locks as we can do more parallelism now.
Yes, with multithreaded processes like these where threads are mapping
and accessing memory areas, per-VMA locks should allow for greater
parallelism. So, if there is a race like the one I asked above, it
might become more pronounced with per-VMA locks.
I'll double check the code, but from Kernel's POV mmap would take the
mmap_lock for write then will lock the VMA lock for write. That should
prevent any page fault handlers from accessing this VMA in parallel
until writers release the locks. Page fault path would try to find the
VMA without any lock and then will try to read-lock that VMA. If it
fails it will fall back to mmap_lock. So, if the writer started first
and obtained the VMA lock, the reader will fall back to mmap_lock and
will block until the writer releases the mmap_lock. If the reader got
VMA read lock first then the writer will block while obtaining the
VMA's write lock. However for your scenario, the reader (page fault)
might be getting here before the writer (mmap) and upon not finding
the VMA it is looking for, it will fail.
Please let me know if you can verify this scenario.
Thanks,
Suren.
>
> There are older hard to reproduce bugs in go with similar symptoms (we
> see this error sometimes now too):
> https://github.com/golang/go/issues/15246
>
> Or this 2016 bug is a red herring. Hard to tell...
>
> >> thanks,
> --
> js
> suse labs
>
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-6.5-1 tag
The pull request you sent on Fri, 30 Jun 2023 20:45:58 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-6.5-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d8b0bd57c2d68eb500f356f0f9228e6183da94ae Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[powerpc:topic/cpu-smt] BUILD SUCCESS 0d882f835c76e5b4e1c7a22443ce85e096cf2be8
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/cpu-smt branch HEAD: 0d882f835c76e5b4e1c7a22443ce85e096cf2be8 powerpc/pseries: Honour current SMT state when DLPAR onlining CPUs elapsed time: 721m configs tested: 106 configs skipped: 5 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alpha defconfig gcc alpharandconfig-r024-20230630 gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-r043-20230630 gcc arm allmodconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-r004-20230629 clang arm randconfig-r046-20230630 gcc arm64allyesconfig gcc arm64 defconfig gcc cskydefconfig gcc hexagon randconfig-r041-20230630 clang hexagon randconfig-r045-20230630 clang i386 allyesconfig gcc i386 buildonly-randconfig-r004-20230629 gcc i386 buildonly-randconfig-r005-20230629 gcc i386 buildonly-randconfig-r006-20230629 gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-i001-20230629 gcc i386 randconfig-i002-20230629 gcc i386 randconfig-i003-20230629 gcc i386 randconfig-i004-20230629 gcc i386 randconfig-i005-20230629 gcc i386 randconfig-i006-20230629 gcc i386 randconfig-i011-20230629 clang i386 randconfig-i012-20230629 clang i386 randconfig-i013-20230629 clang i386 randconfig-i014-20230629 clang i386 randconfig-i015-20230629 clang i386 randconfig-i016-20230629 clang i386 randconfig-r025-20230630 clang loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68k allyesconfig gcc m68kdefconfig gcc m68k randconfig-r026-20230630 gcc m68k randconfig-r035-20230629 gcc mips allmodconfig gcc mips allyesconfig gcc mips randconfig-r001-20230629 clang mips randconfig-r014-20230630 gcc nios2 defconfig gcc openrisc randconfig-r015-20230630 gcc parisc allyesconfig gcc parisc defconfig gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc randconfig-r006-20230629 gcc powerpc randconfig-r032-20230629 gcc riscvallmodconfig gcc riscv allnoconfig gcc riscvallyesconfig gcc riscv defconfig gcc riscvrandconfig-r042-20230630 clang riscv rv32_defconfig gcc s390 allmodconfig gcc s390 allyesconfig gcc s390defconfig gcc s390 randconfig-r005-20230629 gcc s390 randconfig-r011-20230630 clang s390 randconfig-r044-20230630 clang sh allmodconfig gcc sh randconfig-r033-20230629 gcc sparcallyesconfig gcc sparc defconfig gcc sparcrandconfig-r013-20230630 gcc sparcrandconfig-r031-20230629 gcc sparc64 randconfig-r002-20230629 gcc um allmodconfig clang umallnoconfig clang um allyesconfig clang um defconfig gcc um i386_defconfig gcc um randconfig-r016-20230630 gcc um randconfig-r034-20230629 clang um randconfig-r036-20230629 clang um x86_64_defconfig gcc x86_64 allyesconfig gcc x86_64
Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page
On Fri, 30 Jun 2023 08:28:54 -0700 (PDT)
Hugh Dickins wrote:
> On Fri, 30 Jun 2023, Claudio Imbrenda wrote:
> > On Tue, 20 Jun 2023 00:51:19 -0700 (PDT)
> > Hugh Dickins wrote:
> >
> > [...]
> >
> > > +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable)
> > > +{
> > > + unsigned int bit, mask;
> > > + struct page *page;
> > > +
> > > + page = virt_to_page(pgtable);
> > > + if (mm_alloc_pgste(mm)) {
> > > + call_rcu(&page->rcu_head, pte_free_pgste);
> >
> > so is this now going to be used to free page tables
> > instead of page_table_free_rcu?
>
> No.
>
> All pte_free_defer() is being used for (in this series; and any future
> use beyond this series will have to undertake its own evaluations) is
> for the case of removing an empty page table, which used to map a group
> of PTE mappings of a file, in order to make way for one PMD mapping of
> the huge page which those scattered pages have now been gathered into.
>
> You're worried by that mm_alloc_pgste() block: it's something I didn't
actually no, but thanks for bringing it up :D
> have at all in my first draft, then I thought that perhaps the pgste
> case might be able to come this way, so it seemed stupid to leave out
> the handling for it.
>
> I hope that you're implying that should be dead code here? Perhaps,
> that the pgste case corresponds to the case in s390 where THPs are
> absolutely forbidden? That would be good news for us.
>
> Gerald, in his version of this block, added a comment asking:
> /*
>* TODO: Do we need gmap_unlink(mm, pgtable, addr), like in
>* page_table_free_rcu()?
>* If yes -> need addr parameter here, like in pte_free_tlb().
>*/
> Do you have the answer to that? Neither of us could work it out.
this is the thing I'm worried about; removing a page table that was
used to map a guest will leave dangling pointers in the gmap that will
cause memory corruption (I actually ran into that problem myself for
another patchseries).
gmap_unlink() is needed to clean up the pointers before they become
dangling (and also potentially do some TLB purging as needed)
the point here is: we need that only for page_table_free_rcu(); all
other users of page_table_free() cannot act on guest page tables
(because we don't allow THP for KVM guests). and that is why
page_table_free() does not do gmap_unlink() currently.
>
> >
> > or will it be used instead of page_table_free?
>
> Not always; but yes, this case of removing a page table used
> page_table_free() before; but now, with the lighter locking, needs
> to keep the page table valid until the RCU grace period expires.
so if I understand correctly your code will, sometimes, under some
circumstances, replace what page_table_free() does, but it will never
replace page_table_free_rcu()?
because in that case there would be no issues
>
> >
> > this is actually quite important for KVM on s390
>
> None of us are wanting to break KVM on s390: your guidance appreciated!
>
> Thanks,
> Hugh
Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page
On Fri, 30 Jun 2023, Claudio Imbrenda wrote:
> On Tue, 20 Jun 2023 00:51:19 -0700 (PDT)
> Hugh Dickins wrote:
>
> [...]
>
> > +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable)
> > +{
> > + unsigned int bit, mask;
> > + struct page *page;
> > +
> > + page = virt_to_page(pgtable);
> > + if (mm_alloc_pgste(mm)) {
> > + call_rcu(&page->rcu_head, pte_free_pgste);
>
> so is this now going to be used to free page tables
> instead of page_table_free_rcu?
No.
All pte_free_defer() is being used for (in this series; and any future
use beyond this series will have to undertake its own evaluations) is
for the case of removing an empty page table, which used to map a group
of PTE mappings of a file, in order to make way for one PMD mapping of
the huge page which those scattered pages have now been gathered into.
You're worried by that mm_alloc_pgste() block: it's something I didn't
have at all in my first draft, then I thought that perhaps the pgste
case might be able to come this way, so it seemed stupid to leave out
the handling for it.
I hope that you're implying that should be dead code here? Perhaps,
that the pgste case corresponds to the case in s390 where THPs are
absolutely forbidden? That would be good news for us.
Gerald, in his version of this block, added a comment asking:
/*
* TODO: Do we need gmap_unlink(mm, pgtable, addr), like in
* page_table_free_rcu()?
* If yes -> need addr parameter here, like in pte_free_tlb().
*/
Do you have the answer to that? Neither of us could work it out.
>
> or will it be used instead of page_table_free?
Not always; but yes, this case of removing a page table used
page_table_free() before; but now, with the lighter locking, needs
to keep the page table valid until the RCU grace period expires.
>
> this is actually quite important for KVM on s390
None of us are wanting to break KVM on s390: your guidance appreciated!
Thanks,
Hugh
Re: [PATCH v3 8/9] powerpc: Add HOTPLUG_SMT support
Hi Michael,
Le 29/06/2023 à 16:31, Laurent Dufour a écrit :
From: Michael Ellerman
Add support for HOTPLUG_SMT, which enables the generic sysfs SMT support
files in /sys/devices/system/cpu/smt, as well as the "nosmt" boot
parameter.
Implement the recently added hooks to allow partial SMT states, allow
any number of threads per core.
Tie the config symbol to HOTPLUG_CPU, which enables it on the major
platforms that support SMT. If there are other platforms that want the
SMT support that can be tweaked in future.
Signed-off-by: Michael Ellerman
[ldufour: pass current SMT level to cpu_smt_set_num_threads]
[ldufour: remove topology_smt_supported]
[ldufour: remove topology_smt_threads_supported]
[ldufour: select CONFIG_SMT_NUM_THREADS_DYNAMIC]
[ldufour: update kernel-parameters.txt]
Signed-off-by: Laurent Dufour
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++--
arch/powerpc/Kconfig| 2 ++
arch/powerpc/include/asm/topology.h | 15 +++
arch/powerpc/kernel/smp.c | 8 +++-
4 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 9e5bab29685f..5efb6c73a928 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3838,10 +3838,10 @@
nosmp [SMP] Tells an SMP kernel to act as a UP kernel,
and disable the IO APIC. legacy for "maxcpus=0".
- nosmt [KNL,S390] Disable symmetric multithreading (SMT).
+ nosmt [KNL,S390,PPC] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
- [KNL,X86] Disable symmetric multithreading (SMT).
+ [KNL,X86,PPC] Disable symmetric multithreading (SMT).
nosmt=force: Force disable SMT, cannot be undone
via the sysfs control file.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8b955bc7b59f..bacabc3d7f0c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -273,6 +273,8 @@ config PPC
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_VIRT_CPU_ACCOUNTING
select HAVE_VIRT_CPU_ACCOUNTING_GEN
+ select HOTPLUG_SMT if HOTPLUG_CPU
+ select SMT_NUM_THREADS_DYNAMIC
I missed that this list should be kept sorted alphabetically.
Could you fix that when applying the series, or should I send a new
version ?
Thanks,
Laurent.
select HUGETLB_PAGE_SIZE_VARIABLE if PPC_BOOK3S_64 && HUGETLB_PAGE
select IOMMU_HELPER if PPC64
select IRQ_DOMAIN
diff --git a/arch/powerpc/include/asm/topology.h
b/arch/powerpc/include/asm/topology.h
index 8a4d4f4d9749..f4e6f2dd04b7 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -143,5 +143,20 @@ static inline int cpu_to_coregroup_id(int cpu)
#endif
#endif
+#ifdef CONFIG_HOTPLUG_SMT
+#include
+#include
+
+static inline bool topology_is_primary_thread(unsigned int cpu)
+{
+ return cpu == cpu_first_thread_sibling(cpu);
+}
+
+static inline bool topology_smt_thread_allowed(unsigned int cpu)
+{
+ return cpu_thread_in_core(cpu) < cpu_smt_num_threads;
+}
+#endif
+
#endif /* __KERNEL__ */
#endif/* _ASM_POWERPC_TOPOLOGY_H */
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 406e6d0ffae3..eb539325dff8 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1087,7 +1087,7 @@ static int __init init_big_cores(void)
void __init smp_prepare_cpus(unsigned int max_cpus)
{
- unsigned int cpu;
+ unsigned int cpu, num_threads;
DBG("smp_prepare_cpus\n");
@@ -1154,6 +1154,12 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
if (smp_ops && smp_ops->probe)
smp_ops->probe();
+
+ // Initalise the generic SMT topology support
+ num_threads = 1;
+ if (smt_enabled_at_boot)
+ num_threads = smt_enabled_at_boot;
+ cpu_smt_set_num_threads(num_threads, threads_per_core);
}
void smp_prepare_boot_cpu(void)
Re: [PATCH v3 0/9] Introduce SMT level and add PowerPC support
Le 30/06/2023 à 15:32, Sachin Sant a écrit : On 29-Jun-2023, at 8:01 PM, Laurent Dufour wrote: I'm taking over the series Michael sent previously [1] which is smartly reviewing the initial series I sent [2]. This series is addressing the comments sent by Thomas and me on the Michael's one. Here is a short introduction to the issue this series is addressing: When a new CPU is added, the kernel is activating all its threads. This leads to weird, but functional, result when adding CPU on a SMT 4 system for instance. Here the newly added CPU 1 has 8 threads while the other one has 4 threads active (system has been booted with the 'smt-enabled=4' kernel option): ltcden3-lp12:~ # ppc64_cpu --info Core 0:0*1*2*3*4 5 6 7 Core 1:8*9* 10* 11* 12* 13* 14* 15* This mixed SMT level may confused end users and/or some applications. There is no SMT level recorded in the kernel (common code), neither in user space, as far as I know. Such a level is helpful when adding new CPU or when optimizing the energy efficiency (when reactivating CPUs). When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT level (cpu_smt_num_threads) and few callbacks allowing the architecture code to fine control this value, setting a max and a "at boot" level, and controling whether a thread should be onlined or not. v3: Fix a build error in the patch 6/9 Successfully tested the V3 version on a Power10 LPAR. Add/remove of processor core worked correctly, preserving the SMT level (on a kernel booted with smt-enabled= parameter) Laurent (Thanks!) also provided a patch to update the ppc64_cpu & lparstat utility. With patched ppc64_cpu utility verified that SMT level changed at runtime was preserved across processor core add (on a kernel booted without smt-enabled= parameter) Based on these test results Tested-by: Sachin Sant Thanks a lot, Sachin! Once this series is accepted, I'll send the series to update ppc64_cpu.
Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page
On Tue, 20 Jun 2023 00:51:19 -0700 (PDT)
Hugh Dickins wrote:
[...]
> @@ -407,6 +429,77 @@ void __tlb_remove_table(void *_table)
> __free_page(page);
> }
>
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> +static void pte_free_now0(struct rcu_head *head);
> +static void pte_free_now1(struct rcu_head *head);
> +
> +static void pte_free_pgste(struct rcu_head *head)
> +{
> + unsigned long *table;
> + struct page *page;
> +
> + page = container_of(head, struct page, rcu_head);
> + table = (unsigned long *)page_to_virt(page);
> + table = (unsigned long *)((unsigned long)table | 0x03U);
> + __tlb_remove_table(table);
> +}
> +
> +static void pte_free_half(struct rcu_head *head, unsigned int bit)
> +{
> + unsigned long *table;
> + struct page *page;
> + unsigned int mask;
> +
> + page = container_of(head, struct page, rcu_head);
> + mask = atomic_xor_bits(&page->_refcount, 0x04U << (bit + 24));
> +
> + table = (unsigned long *)page_to_virt(page);
> + table += bit * PTRS_PER_PTE;
> + table = (unsigned long *)((unsigned long)table | (0x01U << bit));
> + __tlb_remove_table(table);
> +
> + /* If pte_free_defer() of the other half came in, queue it now */
> + if (mask & 0x0CU)
> + call_rcu(&page->rcu_head, bit ? pte_free_now0 : pte_free_now1);
> +}
> +
> +static void pte_free_now0(struct rcu_head *head)
> +{
> + pte_free_half(head, 0);
> +}
> +
> +static void pte_free_now1(struct rcu_head *head)
> +{
> + pte_free_half(head, 1);
> +}
> +
> +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable)
> +{
> + unsigned int bit, mask;
> + struct page *page;
> +
> + page = virt_to_page(pgtable);
> + if (mm_alloc_pgste(mm)) {
> + call_rcu(&page->rcu_head, pte_free_pgste);
so is this now going to be used to free page tables
instead of page_table_free_rcu?
or will it be used instead of page_table_free?
this is actually quite important for KVM on s390
> + return;
> + }
> + bit = ((unsigned long)pgtable & ~PAGE_MASK) /
> + (PTRS_PER_PTE * sizeof(pte_t));
> +
> + spin_lock_bh(&mm_pgtable_list_lock);
> + mask = atomic_xor_bits(&page->_refcount, 0x15U << (bit + 24));
> + mask >>= 24;
> + /* Other half not allocated? Other half not already pending free? */
> + if ((mask & 0x03U) == 0x00U && (mask & 0x30U) != 0x30U)
> + list_del(&page->lru);
> + spin_unlock_bh(&mm_pgtable_list_lock);
> +
> + /* Do not relink on rcu_head if other half already linked on rcu_head */
> + if ((mask & 0x0CU) != 0x0CU)
> + call_rcu(&page->rcu_head, bit ? pte_free_now1 : pte_free_now0);
> +}
> +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
> +
> /*
> * Base infrastructure required to generate basic asces, region, segment,
> * and page tables that do not make use of enhanced features like EDAT1.
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 306a3d1a0fa6..1667a1bdb8a8 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -146,7 +146,7 @@ struct page {
> pgtable_t pmd_huge_pte; /* protected by page->ptl */
> unsigned long _pt_pad_2;/* mapping */
> union {
> - struct mm_struct *pt_mm; /* x86 pgds only */
> + struct mm_struct *pt_mm; /* x86 pgd, s390 */
> atomic_t pt_frag_refcount; /* powerpc */
> };
> #if ALLOC_SPLIT_PTLOCKS
Re: [PATCH v3 0/9] Introduce SMT level and add PowerPC support
> On 29-Jun-2023, at 8:01 PM, Laurent Dufour wrote: > > I'm taking over the series Michael sent previously [1] which is smartly > reviewing the initial series I sent [2]. This series is addressing the > comments sent by Thomas and me on the Michael's one. > > Here is a short introduction to the issue this series is addressing: > > When a new CPU is added, the kernel is activating all its threads. This > leads to weird, but functional, result when adding CPU on a SMT 4 system > for instance. > > Here the newly added CPU 1 has 8 threads while the other one has 4 threads > active (system has been booted with the 'smt-enabled=4' kernel option): > > ltcden3-lp12:~ # ppc64_cpu --info > Core 0:0*1*2*3*4 5 6 7 > Core 1:8*9* 10* 11* 12* 13* 14* 15* > > This mixed SMT level may confused end users and/or some applications. > > There is no SMT level recorded in the kernel (common code), neither in user > space, as far as I know. Such a level is helpful when adding new CPU or > when optimizing the energy efficiency (when reactivating CPUs). > > When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT level > (cpu_smt_num_threads) and few callbacks allowing the architecture code to > fine control this value, setting a max and a "at boot" level, and > controling whether a thread should be onlined or not. > > v3: > Fix a build error in the patch 6/9 Successfully tested the V3 version on a Power10 LPAR. Add/remove of processor core worked correctly, preserving the SMT level (on a kernel booted with smt-enabled= parameter) Laurent (Thanks!) also provided a patch to update the ppc64_cpu & lparstat utility. With patched ppc64_cpu utility verified that SMT level changed at runtime was preserved across processor core add (on a kernel booted without smt-enabled= parameter) Based on these test results Tested-by: Sachin Sant - Sachin
Re: [PATCH v3 12/13] s390/kexec: refactor for kernel/Kconfig.kexec
On Mon, Jun 26, 2023 at 12:13:31PM -0400, Eric DeVolder wrote:
> The kexec and crash kernel options are provided in the common
> kernel/Kconfig.kexec. Utilize the common options and provide
> the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the
> equivalent set of KEXEC and CRASH options.
>
> NOTE: The original Kconfig has a KEXEC_SIG which depends on
> MODULE_SIG_FORMAT. However, attempts to keep the MODULE_SIG_FORMAT
> dependency (using the strategy outlined in this series, and other
> techniques) results in 'error: recursive dependency detected'
> on CRYPTO.
>
> Per Alexander Gordeev : "the MODULE_SIG_FORMAT
> dependency was introduced with [git commit below] and in fact was not
> necessary, since s390 did/does not use mod_check_sig() anyway.
>
> commit c8424e776b09 ("MODSIGN: Export module signature definitions")
>
> MODULE_SIG_FORMAT is needed to select SYSTEM_DATA_VERIFICATION. But
> SYSTEM_DATA_VERIFICATION is also selected by FS_VERITY*, so dropping
> MODULE_SIG_FORMAT does not hurt."
>
> Therefore, the solution is to drop the MODULE_SIG_FORMAT dependency
> from KEXEC_SIG. Still results in equivalent .config files for s390.
>
> Signed-off-by: Eric DeVolder
> ---
> arch/s390/Kconfig | 65 ++-
> 1 file changed, 19 insertions(+), 46 deletions(-)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 6dab9c1be508..58dc124433ca 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -243,6 +243,25 @@ config PGTABLE_LEVELS
>
> source "kernel/livepatch/Kconfig"
>
> +config ARCH_DEFAULT_KEXEC
> + def_bool y
> +
> +config ARCH_SUPPORTS_KEXEC
> + def_bool y
> +
> +config ARCH_SUPPORTS_KEXEC_FILE
> + def_bool CRYPTO && CRYPTO_SHA256 && CRYPTO_SHA256_S390
> +
> +config ARCH_HAS_KEXEC_PURGATORY
> + def_bool KEXEC_FILE
> +
> +config ARCH_SUPPORTS_CRASH_DUMP
> + def_bool y
> + help
> + Refer to for more details on
> this.
> + This option also enables s390 zfcpdump.
> + See also
> +
> menu "Processor type and features"
>
> config HAVE_MARCH_Z10_FEATURES
> @@ -481,36 +500,6 @@ config SCHED_TOPOLOGY
>
> source "kernel/Kconfig.hz"
>
> -config KEXEC
> - def_bool y
> - select KEXEC_CORE
> -
> -config KEXEC_FILE
> - bool "kexec file based system call"
> - select KEXEC_CORE
> - depends on CRYPTO
> - depends on CRYPTO_SHA256
> - depends on CRYPTO_SHA256_S390
> - help
> - Enable the kexec file based system call. In contrast to the normal
> - kexec system call this system call takes file descriptors for the
> - kernel and initramfs as arguments.
> -
> -config ARCH_HAS_KEXEC_PURGATORY
> - def_bool y
> - depends on KEXEC_FILE
> -
> -config KEXEC_SIG
> - bool "Verify kernel signature during kexec_file_load() syscall"
> - depends on KEXEC_FILE && MODULE_SIG_FORMAT
> - help
> - This option makes kernel signature verification mandatory for
> - the kexec_file_load() syscall.
> -
> - In addition to that option, you need to enable signature
> - verification for the corresponding kernel image type being
> - loaded in order for this to work.
> -
> config KERNEL_NOBP
> def_bool n
> prompt "Enable modified branch prediction for the kernel by default"
> @@ -732,22 +721,6 @@ config VFIO_AP
>
> endmenu
>
> -menu "Dump support"
> -
> -config CRASH_DUMP
> - bool "kernel crash dumps"
> - select KEXEC
> - help
> - Generate crash dump after being started by kexec.
> - Crash dump kernels are loaded in the main kernel with kexec-tools
> - into a specially reserved region and then later executed after
> - a crash by kdump/kexec.
> - Refer to for more details on
> this.
> - This option also enables s390 zfcpdump.
> - See also
> -
> -endmenu
> -
> config CCW
> def_bool y
Acked-by: Alexander Gordeev
Re: [PATCH 07/12] arch/x86: Declare edid_info in
On Fri, Jun 30, 2023, at 09:46, Thomas Zimmermann wrote:
> Am 29.06.23 um 15:21 schrieb Arnd Bergmann:
>> On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote:
>>> Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>
>>>
>>> FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO
>>> announces an architecture feature. They do different things.
>>
>> I still have trouble seeing the difference.
>
> The idea here is that ARCH_HAS_ signals the architecture's support for
> the feature. Drivers set 'depends on' in their Kconfig.
>
> Another Kconfig token, VIDEO_SCREEN_INFO or FIRMWARE_EDID, would then
> actually enable the feature. Drivers select VIDEO_SCREEN_INFO or
> FIRMWARE_EDID and the architectures contains code like
Fair enough. In that case, I guess FIRMWARE_EDID will just depend on
ARCH_HAS_EDID_INFO, or possibly "depends on FIRMWARE_EDID || EFI"
after it starts calling into an EFI specific function, right?
> #ifdef VIDEO_SCREEN_INFO
> struct screen_info screen_info = {
> /* set values here */
> }
> #endif
>
> This allows us to disable code that requires screen_info/edid_info, but
> also disable screen_info/edid_info unless such code has been enabled in
> the kernel config.
>
> Some architectures currently mimic this by guarding screen_info with
> ifdef CONFIG_VT or similar. I'd like to make this more flexible. The
> cost of a few more internal Kconfig tokens seems negligible.
I definitely get it for the screen_info, which needs the complexity.
For ARCHARCH_HAS_EDID_INFO I would hope that it's never selected by
anything other than x86, so I would still go with just a dependency
on x86 for simplicity, but I don't mind having the extra symbol if that
keeps it more consistent with how the screen_info is handled.
>> I suppose you could use FIRMWARE_EDID on EFI or OF systems without
>> the need for a global edid_info structure, but that would not
>> share any code with the current fb_firmware_edid() function.
>
> The current code is build on top of screen_info and edid_info. I'd
> preferably not replace that, if possible.
One way I could imagine this looking in the end would be
something like
struct screen_info *fb_screen_info(struct device *dev)
{
struct screen_info *si = NULL;
if (IS_ENABLED(CONFIG_EFI))
si = efi_get_screen_info(dev);
if (IS_ENABLED(CONFIG_ARCH_HAS_SCREEN_INFO) && !si)
si = screen_info;
return si;
}
corresponding to fb_firmware_edid(). With this, any driver
that wants to access screen_info would call this function
instead of using the global pointer, plus either NULL pointer
check or a CONFIG_ARCH_HAS_SCREEN_INFO dependency.
This way we could completely eliminate the global screen_info
on arm64, riscv, and loongarch but still use the efi and
hyperv framebuffer/drm drivers.
Arnd
Re: [PATCH 4/6] ASoC: fsl_asrc: Add memory to memory driver
On Fri, Jun 30, 2023 at 11:37:29AM +0800, Shengjiu Wang wrote: > On Thu, Jun 29, 2023 at 7:39 PM Mark Brown wrote: > > On Thu, Jun 29, 2023 at 09:37:51AM +0800, Shengjiu Wang wrote: > > > Implement the ASRC memory to memory function using > > > the v4l2 framework, user can use this function with > > > v4l2 ioctl interface. > > This feels like the bit where we interface v4l to ASoC should be a > > separate library, there shouldn't be anything device specific about > > getting an audio stream into a block of memory. I'm thinking something > > like the way we handle dmaengine here. > > I've not dug into the code yet though. > Users may want to get the ASRC output in the user space, then > do mixing with other streams before sending to ALSA. > As there is no such API in ASoC, the best interface I found is > the V4L2, but I need to do a little modification of the V4L2 API, > extend it for audio usage. > Could you please suggest more about the "separate library"? > Should I place this "sound/soc/fsl/fsl_asrc_m2m.c" in another folder? The concept of connecting an audio stream from v4l directly to something in ASoC isn't specific to this driver or even to the i.MX platform, the code that deals with that part of things should be split out so that it works the same for any other drivers that do this. signature.asc Description: PGP signature
[GIT PULL] Please pull powerpc/linux.git powerpc-6.5-1 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull powerpc updates for 6.5. No conflicts that I'm aware of. Notable out of area changes: kernel/kcsan/core.c # 353e7300a1db kcsan: Don't expect 64 bits atomic builtins from 32 bits architectures arch/xtensa/lib/kcsan-stubs.c # bcea4f7a70dc xtensa: Remove 64 bits atomic builtins stubs arch/xtensa/lib/Makefile # bcea4f7a70dc xtensa: Remove 64 bits atomic builtins stubs arch/xtensa/lib/kcsan-stubs.c # bcea4f7a70dc xtensa: Remove 64 bits atomic builtins stubs include/uapi/linux/elf.h # 97228ca375c7 powerpc/ptrace: Expose HASHKEYR register to ptrace scripts/Makefile.compiler # 54a11654de16 powerpc: remove checks for binutils older than 2.25 cheers The following changes since commit f1fcbaa18b28dec10281551dfe6ed3a3ed80e3d6: Linux 6.4-rc2 (2023-05-14 12:51:40 -0700) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.5-1 for you to fetch changes up to 54a11654de163994e32b24e3aa90ef81f4a3184d: powerpc: remove checks for binutils older than 2.25 (2023-06-27 16:59:29 +1000) - -- powerpc updates for 6.5 - Extend KCSAN support to 32-bit and BookE. Add some KCSAN annotations. - Make ELFv2 ABI the default for 64-bit big-endian kernel builds, and use the -mprofile-kernel option (kernel specific ftrace ABI) for big endian ELFv2 kernels. - Add initial Dynamic Execution Control Register (DEXCR) support, and allow the ROP protection instructions to be used on Power 10. - Various other small features and fixes. Thanks to: Aditya Gupta, Aneesh Kumar K.V, Benjamin Gray, Brian King, Christophe Leroy, Colin Ian King, Dmitry Torokhov, Gaurav Batra, Jean Delvare, Joel Stanley, Marco Elver, Masahiro Yamada, Nageswara R Sastry, Nathan Chancellor, Naveen N Rao, Nayna Jain, Nicholas Piggin, Paul Gortmaker, Randy Dunlap, Rob Herring, Rohan McLure, Russell Currey, Sachin Sant, Timothy Pearson, Tom Rix, Uwe Kleine-König. - -- Aditya Gupta (1): powerpc: update ppc_save_regs to save current r1 in pt_regs Aneesh Kumar K.V (4): powerpc/mm/book3s64: Use pmdp_ptep helper instead of typecasting. powerpc/book3s64/mm: Fix DirectMap stats in /proc/meminfo powerpc/book3s64/mm: Use PAGE_KERNEL instead of opencoding powerpc/mm/dax: Fix the condition when checking if altmap vmemap can cross-boundary Benjamin Gray (11): powerpc/book3s: Add missing include powerpc/ptrace: Add missing include powerpc/dexcr: Add initial Dynamic Execution Control Register (DEXCR) support powerpc/dexcr: Handle hashchk exception powerpc/dexcr: Support userspace ROP protection powerpc/ptrace: Expose DEXCR and HDEXCR registers to ptrace powerpc/ptrace: Expose HASHKEYR register to ptrace Documentation: Document PowerPC kernel DEXCR interface selftests/powerpc: Add more utility macros selftests/powerpc/dexcr: Add hashst/hashchk test selftests/powerpc/dexcr: Add DEXCR status utility lsdexcr Christophe Leroy (5): kcsan: Don't expect 64 bits atomic builtins from 32 bits architectures xtensa: Remove 64 bits atomic builtins stubs powerpc/kcsan: Properly instrument arch_spin_unlock() powerpc/interrupt: Don't read MSR from interrupt_exit_kernel_prepare() powerpc/signal32: Force inlining of __unsafe_save_user_regs() and save_tm_user_regs_unsafe() Colin Ian King (1): powerpc/powernv/sriov: perform null check on iov before dereferencing iov Gaurav Batra (1): powerpc/iommu: TCEs are incorrectly manipulated with DLPAR add/remove of memory Joel Stanley (3): powerpc/powernv/pci: Remove ioda1 support powerpc/powernv/pci: Remove MVE code powerpc/powernv/pci: Remove last IODA1 defines Masahiro Yamada (1): powerpc: remove checks for binutils older than 2.25 Michael Ellerman (3): Merge branch 'fixes' into next MAINTAINERS: Exclude m68k-only drivers from powerpc entry powerpc: Mark powermac as orphan in MAINTAINERS Naveen N Rao (2): powerpc/ftrace: Disable ftrace on ppc32 if using clang powerpc: Fail build if using recordmcount with binutils v2.37 Nayna Jain (1): security/integrity: fix pointer to ESL data and its size on pseries Nicholas Piggin (19): KVM: PPC: Update MAINTAINERS powerpc/boot: Separate target flags from BOOTCFLAGS powerpc/boot: Separate CPP flags from BOOTCFLAGS powerpc/boot: Separate BOOTCFLAGS from BOOTASFLAGS powerpc/boot: Clean up Makefile after cflags and asflags separation powerpc/build: Remove -pipe from compilation flags powerpc/64: Force ELFv2 when building with LLVM linker powerpc/64: Make ELFv2 the default for big-endian builds powerpc/64: Use
Re: [PATCH 1/6] media: v4l2: Add audio capture and output support
Hi Shengjiu,
On Thu, Jun 29, 2023 at 09:37:48AM +0800, Shengjiu Wang wrote:
> Audio signal processing has the requirement for memory to
> memory similar as Video.
>
> This patch is to add this support in v4l2 framework, defined
> new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and
> V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format
> for audio case usage.
Why are you proposing to add this to V4L2 framework instead of doing this
within ALSA?
Also cc Hans and Jacopo.
>
> The created audio device is named "/dev/audioX".
>
> Signed-off-by: Shengjiu Wang
> ---
> .../media/common/videobuf2/videobuf2-v4l2.c | 4 ++
> drivers/media/v4l2-core/v4l2-dev.c| 17 ++
> drivers/media/v4l2-core/v4l2-ioctl.c | 52 +++
> include/media/v4l2-dev.h | 2 +
> include/media/v4l2-ioctl.h| 34
> include/uapi/linux/videodev2.h| 19 +++
> 6 files changed, 128 insertions(+)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index c7a54d82a55e..12f2be2773a2 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -785,6 +785,10 @@ int vb2_create_bufs(struct vb2_queue *q, struct
> v4l2_create_buffers *create)
> case V4L2_BUF_TYPE_META_OUTPUT:
> requested_sizes[0] = f->fmt.meta.buffersize;
> break;
> + case V4L2_BUF_TYPE_AUDIO_CAPTURE:
> + case V4L2_BUF_TYPE_AUDIO_OUTPUT:
> + requested_sizes[0] = f->fmt.audio.buffersize;
> + break;
> default:
> return -EINVAL;
> }
> diff --git a/drivers/media/v4l2-core/v4l2-dev.c
> b/drivers/media/v4l2-core/v4l2-dev.c
> index f81279492682..67484f4c6eaf 100644
> --- a/drivers/media/v4l2-core/v4l2-dev.c
> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> @@ -553,6 +553,7 @@ static void determine_valid_ioctls(struct video_device
> *vdev)
> bool is_tch = vdev->vfl_type == VFL_TYPE_TOUCH;
> bool is_meta = vdev->vfl_type == VFL_TYPE_VIDEO &&
> (vdev->device_caps & meta_caps);
> + bool is_audio = vdev->vfl_type == VFL_TYPE_AUDIO;
> bool is_rx = vdev->vfl_dir != VFL_DIR_TX;
> bool is_tx = vdev->vfl_dir != VFL_DIR_RX;
> bool is_io_mc = vdev->device_caps & V4L2_CAP_IO_MC;
> @@ -664,6 +665,19 @@ static void determine_valid_ioctls(struct video_device
> *vdev)
> SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_meta_out);
> SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT, vidioc_try_fmt_meta_out);
> }
> + if (is_audio && is_rx) {
> + /* audio capture specific ioctls */
> + SET_VALID_IOCTL(ops, VIDIOC_ENUM_FMT,
> vidioc_enum_fmt_audio_cap);
> + SET_VALID_IOCTL(ops, VIDIOC_G_FMT, vidioc_g_fmt_audio_cap);
> + SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_audio_cap);
> + SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT, vidioc_try_fmt_audio_cap);
> + } else if (is_audio && is_tx) {
> + /* audio output specific ioctls */
> + SET_VALID_IOCTL(ops, VIDIOC_ENUM_FMT,
> vidioc_enum_fmt_audio_out);
> + SET_VALID_IOCTL(ops, VIDIOC_G_FMT, vidioc_g_fmt_audio_out);
> + SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_audio_out);
> + SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT, vidioc_try_fmt_audio_out);
> + }
> if (is_vbi) {
> /* vbi specific ioctls */
> if ((is_rx && (ops->vidioc_g_fmt_vbi_cap ||
> @@ -927,6 +941,9 @@ int __video_register_device(struct video_device *vdev,
> case VFL_TYPE_TOUCH:
> name_base = "v4l-touch";
> break;
> + case VFL_TYPE_AUDIO:
> + name_base = "audio";
> + break;
> default:
> pr_err("%s called with unknown type: %d\n",
> __func__, type);
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index a858acea6547..26bc4b0d8ef0 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -188,6 +188,8 @@ const char *v4l2_type_names[] = {
> [V4L2_BUF_TYPE_SDR_OUTPUT] = "sdr-out",
> [V4L2_BUF_TYPE_META_CAPTURE] = "meta-cap",
> [V4L2_BUF_TYPE_META_OUTPUT]= "meta-out",
> + [V4L2_BUF_TYPE_AUDIO_CAPTURE] = "audio-cap",
> + [V4L2_BUF_TYPE_AUDIO_OUTPUT] = "audio-out",
> };
> EXPORT_SYMBOL(v4l2_type_names);
>
> @@ -276,6 +278,7 @@ static void v4l_print_format(const void *arg, bool
> write_only)
> const struct v4l2_sliced_vbi_format *sliced;
> const struct v4l2_window *win;
> const struct v4l2_meta_format *meta;
> + const struct v4l2_audio_format *audio;
> u32 pixelformat;
> u32 planes;
> unsigned i;
> @@ -346,6 +349,12 @@ static void v4l_print_format(const vo
Re: [FSL P50x0] [PASEMI] The Access to partitions on disks with an Amiga partition table doesn't work anymore after the block updates 2023-06-23
Hi Michael, hi Christian. Michael Schmitz - 29.06.23, 22:27:59 CEST: […] > On 29/06/23 16:59, Christian Zigotzky wrote: > > Hello, > > > > The access to partitions on disks with an Amiga partition table > > (via the Rigid Disk Block RDB) doesn't work anymore on my Cyrus+ > > board with a FSL P50x0 PowerPC SoC [1] and on my P.A. Semi Nemo > > board [2] after the block updates 2023-06-23 [3]. > > > > parted -l […] > > dmesg | grep -i sda > > > > [4.208905] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: > > (2.00 TB/1.82 TiB) That is roughly the size of the disk that triggered my bug report from 2012. Jun 19 21:19:09 merkaba kernel: [ 7891.821315] ata8.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32) Bug 43511 - Partitions: Amiga RDB partition on 2 TB disk way too big, while OK in AmigaOS 4.1 https://bugzilla.kernel.org/show_bug.cgi?id=43511 > > [4.963387] sda: partition table beyond EOD, > > Haven't see this one in any of my tests. I wonder whether your > partitioning software used that value of 4294967295 (32 bit unsigned > int max.) as marker for the end of the partition list, instead of > NULL? It's clearly beyond the end of your disk, so cannot be a > legitimate partition block address. (The parted dump above (showing > only four partitions) appears to support that notion.) I don't know about "-1" for end of partition list. However, on reviewing my bug report I think I used Media Toolbox myself to create the partition table. However I am not completely sure about that. It has been a long time. I used Media Toolbox on AmigaOS 4.1 to extract the binary copy of the RDB, but I do not recall what I used to partition it. I bet it was Media Toolbox as well, likely on some development version of AmigaOS 4. I was member of the AmigaOS 4 team back then. The disk is repartitioned as GPT and I do not even know at the moment where it is. So that is all I can say. I could ask someone from the AmigaOS 4 team, however I am not a member of it anymore. And in any case, whether Media Toolbox or another tool writes a "-1" to end partition list or not, I'd not treat a signed value "-1" as valid partition size. We could also ask Joanne again, however she was not involved in AmigaOS 4 development and does not know about Media Toolbox. She created the "hdwrench.library" for AmigaOS 3.5/3.9 HDToolBox. So maybe it is just good to assume "-1" as end of partition table, at least after confirming from the binary of the affected RDB that the "-1" is indeed at the end of the partition block list. Maybe also in the RDB from my bug report there is this "-1" again… however, the disk worked okay in Linux after testing with Joanne's initial patch from https://bugzilla.kernel.org/show_bug.cgi?id=43511#c7 Subject: Re: Partitions: Amiga RDB partition on 2 TB disk way too big, while OK in AmigaOS 4.1 https://lore.kernel.org/linux-m68k/ 201206192146.09327.mar...@lichtvoll.de/ This comment from an AmigaOS developer is only about the maximum sizes and does not detail a "-1" as partition size – however I did not ask about it back then: https://lore.kernel.org/linux-m68k/ 201206182239.26647.mar...@lichtvoll.de/ > > [ 5.014769] sd 0:0:0:0: [sda] Attached SCSI disk > > > > I created a patch for reverting the commit. [4] > > > > The access works again with this patch: […] > > bytes [4.519477] sda: RDSK (512) sda1 (DOS^G)(res 2 spb 2) > > sda2 (SFS^B)(res 2 spb 1) sda3 (SFS^B)(res 2 spb 2) sda4 ((res 2 > > spb 1) [4.720896] sda: p4 size 18446744071956107760 extends > > beyond EOD, > > That's the 32 bit overflow that the patch series was meant to correct. > Parsing the partition table ends before looking at the next partition > block in the list, so we never hit the bug you've seen above. > > By reverting my patch, you just reintroduce the old bug, which could > result in mis-parsing the partition table in a way that is not > detected by inane values of partition sizes as above, and as far as I > recall this bug was reported because it did cause data corruption. Do > I have that correct, Martin? Do you still have a copy of the > problematic RDB from the old bug report around? It is in the first attachment of the bug report I mentioned above. The bug the patch fixed. In the bug report I wrote: "I had a BTRFS filesystem that had some checksum errors. Maybe thats somehow related to this issue and AmigaOS and/or Linux overwrote something it shouldn´t have touched." (Meanwhile I bet it is safe to assume that in case the checksum error was from overwriting something it was not AmigaOS 4.) This is no proof, but as I re-read my bug report: It is clearly an overflow issue worsened by Linux back then truncating the too high partition sizes larger than the disk to the disk size instead of bailing out. So the partition I created for the Linux LVM in front of the Amiga partitions overflowed into the Amiga partitions. Had I used that place inside the PV for any LV and writt
Re: [PATCH] syscalls: Cleanup references to sys_lookup_dcookie()
Hello,
On Wed, Jun 28, 2023 at 4:44 PM Randy Dunlap wrote:
>
>
>
> On 6/28/23 16:09, Sohil Mehta wrote:
> > commit 'be65de6b03aa ("fs: Remove dcookies support")' removed the
> > syscall definition for lookup_dcookie. However, syscall tables still
> > point to the old sys_lookup_dcookie() definition. Update syscall tables
> > of all architectures to directly point to sys_ni_syscall() instead.
> >
> > Signed-off-by: Sohil Mehta
>
> Reviewed-by: Randy Dunlap
I was about to say that it'd be nice if you split the tools/perf part
since it can support old kernels. But if the syscall is only used for
oprofile then probably perf doesn't need to care about it. :)
For the perf part,
Acked-by: Namhyung Kim
Thanks,
Namhyung
Re: [PATCH 4/6] ASoC: fsl_asrc: Add memory to memory driver
On Thu, Jun 29, 2023 at 7:39 PM Mark Brown wrote: > On Thu, Jun 29, 2023 at 09:37:51AM +0800, Shengjiu Wang wrote: > > Implement the ASRC memory to memory function using > > the v4l2 framework, user can use this function with > > v4l2 ioctl interface. > > > > User send the output and capture buffer to driver and > > driver store the converted data to the capture buffer. > > > > This feature can be shared by ASRC and EASRC drivers > > > > Signed-off-by: Shengjiu Wang > > --- > > sound/soc/fsl/Kconfig| 13 + > > sound/soc/fsl/Makefile | 2 + > > sound/soc/fsl/fsl_asrc_m2m.c | 878 +++ > > sound/soc/fsl/fsl_asrc_m2m.h | 48 ++ > > This feels like the bit where we interface v4l to ASoC should be a > separate library, there shouldn't be anything device specific about > getting an audio stream into a block of memory. I'm thinking something > like the way we handle dmaengine here. > > I've not dug into the code yet though. > Users may want to get the ASRC output in the user space, then do mixing with other streams before sending to ALSA. As there is no such API in ASoC, the best interface I found is the V4L2, but I need to do a little modification of the V4L2 API, extend it for audio usage. Could you please suggest more about the "separate library"? Should I place this "sound/soc/fsl/fsl_asrc_m2m.c" in another folder? best regards wang shengjiu
Re: [PATCH 3/6] ASoC: fsl_easrc: define functions for memory to memory usage
On Thu, Jun 29, 2023 at 7:00 PM Fabio Estevam wrote: > Hi Shengjiu, > > On Wed, Jun 28, 2023 at 11:10 PM Shengjiu Wang > wrote: > > > > ASRC can be used on memory to memory case, define several > > functions for m2m usage and export them as function pointer. > > > > Signed-off-by: Shengjiu Wang > > Could you please explain what is the benefit of using M2M in the EASRC > driver? > > Users may want to get the ASRC output in the user space, then do mixing with other streams before sending to DAC. so this patch-set is to use the v4l2 API for this usage, because there is no such API in ASoC. > A few weeks ago, an imx8mn user reported that the EASRC with the > mainline kernel introduces huge delays. > > Does M2M help with this aspect? > No, M2M can't help with the delays issue. The delay issue maybe caused by the buffer size or the prefilled data needs by EASRC. Best regards wang shengjiu > > Thanks >
Re: [PATCH] powerpc: Include asm/nmi.c in mobility.c for watchdog_hardlockup_set_timeout_pct()
On Thu 2023-06-29 12:45:06, Douglas Anderson wrote:
> The powerpc/platforms/pseries/mobility.c calls
> watchdog_hardlockup_set_timeout_pct(), which is declared in
> . We used to automatically get included, but
> that changed as of commit 7ca8fe94aa92 ("watchdog/hardlockup: define
> HARDLOCKUP_DETECTOR_ARCH"). Let's add the explicit include.
>
> Reported-by: Randy Dunlap
> Closes:
> https://lore.kernel.org/r/af19b76d-aa4b-6c88-9cac-eae4b2072...@infradead.org
> Fixes: 7ca8fe94aa92 ("watchdog/hardlockup: define HARDLOCKUP_DETECTOR_ARCH")
> Signed-off-by: Douglas Anderson
Thanks for the patch:
Reviewed-by: Petr Mladek
Best Regards,
Petr
Re: [PATCH v4 29/33] x86/mm: try VMA lock-based page fault handling first
On 30. 06. 23, 10:28, Jiri Slaby wrote:
> 2348
clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, child_tid=0x7fcaa5882990, parent_tid=0x7fcaa5882990, exit_signal=0, stack=0x7fcaa5082000, stack_size=0x7ffe00, tls=0x7fcaa58826c0} => {parent_tid=[2351]}, 88) = 2351
> 2350 <... clone3 resumed> => {parent_tid=[2372]}, 88) = 2372
> 2351 <... clone3 resumed> => {parent_tid=[2354]}, 88) = 2354
> 2351 <... clone3 resumed> => {parent_tid=[2357]}, 88) = 2357
> 2354 <... clone3 resumed> => {parent_tid=[2355]}, 88) = 2355
> 2355 <... clone3 resumed> => {parent_tid=[2370]}, 88) = 2370
> 2370 mmap(NULL, 262144, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0
> 2370 <... mmap resumed>) = 0x7fca68249000
> 2372 <... clone3 resumed> => {parent_tid=[2384]}, 88) = 2384
> 2384 <... clone3 resumed> => {parent_tid=[2388]}, 88) = 2388
> 2388 <... clone3 resumed> => {parent_tid=[2392]}, 88) = 2392
> 2392 <... clone3 resumed> => {parent_tid=[2395]}, 88) = 2395
> 2395 write(2, "runtime: marked free object in s"..., 36 ...>
I.e. IIUC, all are threads (CLONE_VM) and thread 2370 mapped ANON
0x7fca68249000 - 0x7fca6827 and go in thread 2395 thinks for some
reason 0x7fca6824bec8 in that region is "bad".
As I was noticed, this might be as well be a fail of the go's
inter-thread communication (or alike) too. It might now be only more
exposed with vma-based locks as we can do more parallelism now.
There are older hard to reproduce bugs in go with similar symptoms (we
see this error sometimes now too):
https://github.com/golang/go/issues/15246
Or this 2016 bug is a red herring. Hard to tell...
thanks,
--
js
suse labs
Re: [PATCH v4 29/33] x86/mm: try VMA lock-based page fault handling first
On 30. 06. 23, 8:35, Jiri Slaby wrote:
On 29. 06. 23, 17:30, Suren Baghdasaryan wrote:
On Thu, Jun 29, 2023 at 7:40 AM Jiri Slaby wrote:
Hi,
On 27. 02. 23, 18:36, Suren Baghdasaryan wrote:
Attempt VMA lock-based page fault handling first, and fall back to the
existing mmap_lock-based handling if that fails.
Signed-off-by: Suren Baghdasaryan
---
arch/x86/Kconfig | 1 +
arch/x86/mm/fault.c | 36
2 files changed, 37 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a825bf031f49..df21fba77db1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -27,6 +27,7 @@ config X86_64
# Options that are inherently 64-bit kernel only:
select ARCH_HAS_GIGANTIC_PAGE
select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
+ select ARCH_SUPPORTS_PER_VMA_LOCK
select ARCH_USE_CMPXCHG_LOCKREF
select HAVE_ARCH_SOFT_DIRTY
select MODULES_USE_ELF_RELA
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index a498ae1fbe66..e4399983c50c 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -19,6 +19,7 @@
#include /*
faulthandler_disabled() */
#include /*
efi_crash_gracefully_on_page_fault()*/
#include
+#include /* find_and_lock_vma() */
#include /* boot_cpu_has,
... */
#include /* dotraplinkage,
... */
@@ -1333,6 +1334,38 @@ void do_user_addr_fault(struct pt_regs *regs,
}
#endif
+#ifdef CONFIG_PER_VMA_LOCK
+ if (!(flags & FAULT_FLAG_USER))
+ goto lock_mmap;
+
+ vma = lock_vma_under_rcu(mm, address);
+ if (!vma)
+ goto lock_mmap;
+
+ if (unlikely(access_error(error_code, vma))) {
+ vma_end_read(vma);
+ goto lock_mmap;
+ }
+ fault = handle_mm_fault(vma, address, flags |
FAULT_FLAG_VMA_LOCK, regs);
+ vma_end_read(vma);
+
+ if (!(fault & VM_FAULT_RETRY)) {
+ count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
+ goto done;
+ }
+ count_vm_vma_lock_event(VMA_LOCK_RETRY);
This is apparently not strong enough as it causes go build failures
like:
[ 409s] strconv
[ 409s] releasep: m=0x579e2000 m->p=0x5781c600 p->m=0x0 p->status=2
[ 409s] fatal error: releasep: invalid p state
[ 409s]
[ 325s] hash/adler32
[ 325s] hash/crc32
[ 325s] cmd/internal/codesign
[ 336s] fatal error: runtime: out of memory
Hi Jiri,
Thanks for reporting! I'm not familiar with go builds. Could you
please explain the error to me or point me to some documentation to
decipher that error?
Sorry, we are on the same boat -- me neither. It only popped up in our
(openSUSE) build system and I only tracked it down by bisection. Let me
know if I can try something (like a patch or gathering some debug info).
FWIW, a failed build log:
https://decibel.fi.muni.cz/~xslaby/n/vma/log.txt
and a strace for it:
https://decibel.fi.muni.cz/~xslaby/n/vma/strace.txt
An excerpt from the log:
[ 55s] runtime: marked free object in span 0x7fca6824bec8,
elemsize=192 freeindex=0 (bad use of unsafe.Pointer? try -d=checkptr)
[ 55s] 0xc0002f2000 alloc marked
[ 55s] 0xc0002f20c0 alloc marked
[ 55s] 0xc0002f2180 alloc marked
[ 55s] 0xc0002f2240 free unmarked
[ 55s] 0xc0002f2300 alloc marked
[ 55s] 0xc0002f23c0 alloc marked
[ 55s] 0xc0002f2480 alloc marked
[ 55s] 0xc0002f2540 alloc marked
[ 55s] 0xc0002f2600 alloc marked
[ 55s] 0xc0002f26c0 alloc marked
[ 55s] 0xc0002f2780 alloc marked
[ 55s] 0xc0002f2840 alloc marked
[ 55s] 0xc0002f2900 alloc marked
[ 55s] 0xc0002f29c0 free unmarked
[ 55s] 0xc0002f2a80 alloc marked
[ 55s] 0xc0002f2b40 alloc marked
[ 55s] 0xc0002f2c00 alloc marked
[ 55s] 0xc0002f2cc0 alloc marked
[ 55s] 0xc0002f2d80 alloc marked
[ 55s] 0xc0002f2e40 alloc marked
[ 55s] 0xc0002f2f00 alloc marked
[ 55s] 0xc0002f2fc0 alloc marked
[ 55s] 0xc0002f3080 alloc marked
[ 55s] 0xc0002f3140 alloc marked
[ 55s] 0xc0002f3200 alloc marked
[ 55s] 0xc0002f32c0 alloc marked
[ 55s] 0xc0002f3380 free unmarked
[ 55s] 0xc0002f3440 free marked zombie
An excerpt from strace:
> 2348
clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
child_tid=0x7fcaa6a1b990, parent_tid=0x7fcaa6a1b990, exit_signal=0,
stack=0x7fcaa621b000, stack_size=0x7ffe00, tls=0x7fcaa6a1b6c0} =>
{parent_tid=[2350]}, 88) = 2350
> 2348
clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
child_tid=0x7fcaa5882990, parent_tid=0x7fcaa5882990, exit_signal=0,
stack=0x7fcaa5082000, stack_size=0x7ffe00, tls=0x7fcaa58826c0} =>
{parent_tid=[2351]}, 88) = 2351
> 2350 <... clone3 resumed> => {parent_tid=[2372]}, 88) = 2372
> 2351 <... clone3 resumed> => {parent_tid=[2354]}, 88) = 2354
> 2351 <... clone3 resumed> =>
Re: [PATCH 07/12] arch/x86: Declare edid_info in
Hi
Am 29.06.23 um 15:21 schrieb Arnd Bergmann:
On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote:
Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
The global variable edid_info contains the firmware's EDID information
as an extension to the regular screen_info on x86. Therefore move it to
.
Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
architectures that don't provide edid_info. Select it on x86.
I'm not sure we need another symbol in addition to
CONFIG_FIRMWARE_EDID. Since all the code behind that
existing symbol is also x86 specific, would it be enough
to just add either 'depends on X86' or 'depends on X86 ||
COMPILE_TEST' there?
FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO
announces an architecture feature. They do different things.
I still have trouble seeing the difference.
The idea here is that ARCH_HAS_ signals the architecture's support for
the feature. Drivers set 'depends on' in their Kconfig.
Another Kconfig token, VIDEO_SCREEN_INFO or FIRMWARE_EDID, would then
actually enable the feature. Drivers select VIDEO_SCREEN_INFO or
FIRMWARE_EDID and the architectures contains code like
#ifdef VIDEO_SCREEN_INFO
struct screen_info screen_info = {
/* set values here */
}
#endif
This allows us to disable code that requires screen_info/edid_info, but
also disable screen_info/edid_info unless such code has been enabled in
the kernel config.
Some architectures currently mimic this by guarding screen_info with
ifdef CONFIG_VT or similar. I'd like to make this more flexible. The
cost of a few more internal Kconfig tokens seems negligible.
Right now, ARCH_HAS_EDID_INFO only works on the old BIOS-based VESA
systems. In the future, I want to add support for EDID data from EFI and
OF as well. It would be stored in edid_info. I assume that the new
symbol will become useful then.
I don't see why an OF based system would have the same limitation
as legacy BIOS with supporting only a single monitor, if we need
to have a generic representation of EDID data in DT, that would
probably be in a per device property anyway.
Sorry that was my mistake. OF has nothing to do with this.
I suppose you could use FIRMWARE_EDID on EFI or OF systems without
the need for a global edid_info structure, but that would not
share any code with the current fb_firmware_edid() function.
The current code is build on top of screen_info and edid_info. I'd
preferably not replace that, if possible.
Best regards
Thomas
Arnd
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature
Description: OpenPGP digital signature
