linux-kernel - Re: [PATCH RFC] s390/pci: Drop unneeded reference to CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 24 Apr 2024 13:34:49 +0200
From: Niklas Schnelle <schnelle@...ux.ibm.com>
To: Jean Delvare <jdelvare@...e.de>, linux-s390@...r.kernel.org
Cc: LKML <linux-kernel@...r.kernel.org>,
        Gerald Schaefer
 <gerald.schaefer@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>, Vasily
 Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>
Subject: Re: [PATCH RFC] s390/pci: Drop unneeded reference to CONFIG_DMI

On Tue, 2024-04-23 at 16:27 +0200, Jean Delvare wrote:
> The S/390 architecture doesn't support SMBIOS, so CONFIG_DMI will
> never be defined there. So we can simply omit these preprocessing
> directives and speed up the build a bit.
> 
> Signed-off-by: Jean Delvare <jdelvare@...e.de>
> Cc: Niklas Schnelle <schnelle@...ux.ibm.com>
> Cc: Gerald Schaefer <gerald.schaefer@...ux.ibm.com>
> ---
> Niklas, you added these preprocessing directives as part of commit
> 81bbf03905aa ("s390/pci: expose a PCI device's UID as its index").
> I do not understand the purpose. Am I missing something?

This was only done out of an abundance of caution for the very unlikely
case that somehow someday we end up with EFI and DMI on s390x in which
case this code would then collide with the smbios way of getting an
index from firmware. Looking back I think this is indeed not useful and
even if we ever get a collision it would probably need treatment anyway
in which case getting a compile error is probably a good thing and less
code is always good too.

> 
>  arch/s390/pci/pci_sysfs.c |    4 ----
>  1 file changed, 4 deletions(-)
> 
> --- linux-6.8.orig/arch/s390/pci/pci_sysfs.c
> +++ linux-6.8/arch/s390/pci/pci_sysfs.c
> @@ -156,7 +156,6 @@ static ssize_t uid_is_unique_show(struct
>  }
>  static DEVICE_ATTR_RO(uid_is_unique);
>  
> -#ifndef CONFIG_DMI
>  /* analogous to smbios index */
>  static ssize_t index_show(struct device *dev,
>  			  struct device_attribute *attr, char *buf)
> @@ -186,7 +185,6 @@ static struct attribute_group zpci_ident
>  	.attrs = zpci_ident_attrs,
>  	.is_visible = zpci_index_is_visible,
>  };
> -#endif
>  
>  static struct bin_attribute *zpci_bin_attrs[] = {
>  	&bin_attr_util_string,
> @@ -229,8 +227,6 @@ static struct attribute_group pfip_attr_
>  const struct attribute_group *zpci_attr_groups[] = {
>  	&zpci_attr_group,
>  	&pfip_attr_group,
> -#ifndef CONFIG_DMI
>  	&zpci_ident_attr_group,
> -#endif
>  	NULL,
>  };
> 

I'm assuming this change should go via the s390 tree? So let me add the
s390x architecture maintainers to pick this up, but from my side and
considering that you maintain the SMBIOS/DMI support:

Acked-by: Niklas Schnelle <schnelle@...ux.ibm.com>