The Hardware string in /proc/cpuinfo , in IS NOT pointless and misleading.

[pggood]

The hardware string in /proc/cpuinfo is used by a number of applications to determine the type of Raspberry PI is used It appears to be that it has been removed because a few users has complained that it is reporting incorrectly. Its removal is now causing a significant amount of havoc particularly with the use of WiringPI

At this stage I would like to see https://github.com/pelwell/linux/commit/17804c20303c8295b05baf2ab9578432ac5c2735 rolled back

and arch/arm64/kernel/cpuinfo.c updated to detect and report the actual processor rather than simply removing the value which is used to determine if the model of raspeberry pi used

[timg236]

WiringPi had been deprecated for a long time. Please can you elaborate about your particular use case and why the code depends on this particular value ?

[pggood]

from wiringPi.c it makes use of this field with the following code and then goes on to map the pins to the GPIO based on it being either a 26 or 40 pin interface . Removing this entry the WiringPI module wiring PI simply exits with the error

Oops: Unable to determine board revision from /proc/cpuinfo -> No "Hardware" line -> You'd best google the error to find out why.

Given that a large amount of RaspberryPI's use the GPIO pins as process controllers this change breaks a large amount of equipment that has used this feature and wiringPi

int piGpioLayout (void) { FILE cpuFd ; char line [120] ; char c ; static int gpioLayout = -1 ;

if (gpioLayout != -1) // No point checking twice return gpioLayout ;

if ((cpuFd = fopen ("/proc/cpuinfo", "r")) == NULL) piGpioLayoutOops ("Unable to open /proc/cpuinfo") ;

// Start by looking for the Architecture to make sure we're really running // on a Pi. I'm getting fed-up with people whinging at me because // they can't get it to work on weirdFruitPi boards...

while (fgets (line, 120, cpuFd) != NULL) if (strncmp (line, "Hardware", 8) == 0) break ;

[pggood]

What is the alternative to WiringPi

[6by9]

The WiringPi argument is a duplicate of https://github.com/raspberrypi/linux/issues/5783

WiringPi was deprecated by the author in 2019.

It was removed from the Raspberry Pi repos in Jan 2022.

Those who have supported it since 2019 have now dropped it totally as the changes in 6.6 aren't going to be fixed by them (see https://github.com/WiringPi/WiringPi/issues/186)

It also hasn't done anything Revision string for 5 years - https://github.com/WiringPi/WiringPi/blob/master/wiringPi/wiringPi.c#L782-L815 (DONT_CARE_ANYMORE is not defined, so it will never exit if the Hardware name doesn't match). It is a touch stupid that it still calls piGpioLayoutOops if it doesn't find the string, so moving the #ifdef DONT_CARE_ANYMORE to line 767 would be an easy workaround.

[6by9]

What is the alternative to WiringPi

libgpio is the main one as it's developed by the kernel developers who maintain the GPIO subsystem. https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/ If wanting Python, then gpiozero.

[lurch]

If wanting Python, then gpiozero.

Which uses http://abyz.me.uk/lg/py_lgpio.html under the hood.

[lurch]

And FYI https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-pi-revision-codes is the "proper" way to determine what model of Raspberry Pi your code is running on.

[pggood]

Given that this removal of the Hardware reporting from /proc/cpuinfo Breaks WiringPi is there any other business reason for its removal and it there any reasonable reason why this change should not be rolled back

[6by9]

If wanting Python, then gpiozero.

Which uses http://abyz.me.uk/lg/py_lgpio.html under the hood.

AIUI It has a number of backends available.

Given that this removal of the Hardware reporting from /proc/cpuinfo Breaks WiringPi is there any other business reason for its removal and it there any reasonable reason why this change should not be rolled back

You would gain a reprieve of about 3 months until the 6.6 kernel becomes the standard. At which point the base GPIO number for sysfs isn't fixed, and WiringPi fails again as documented in https://github.com/WiringPi/WiringPi/issues/186

[JamesH65]

Given that this removal of the Hardware reporting from /proc/cpuinfo Breaks WiringPi is there any other business reason for its removal and it there any reasonable reason why this change should not be rolled back

Yes, the incorrect reporting of the processor has been an endless source of technical support questions for some years. Removing it from the reporting means those technical support questions go away (after the few apps using it move to the correct scheme). Removing it also means future applications will not use it incorrectly. As referenced above there is a correct and future-proof way of determining the board type, please use that.

[lurch]

If you want to keep using legacy software like WiringPi, I guess you could keep using the Legacy release of Raspberry Pi OS from https://www.raspberrypi.com/software/operating-systems/ ?