Am Di., 9. Nov. 2021 um 13:42 Uhr schrieb Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>: > ... > > Do you have a pointer to these complex and buggy drivers anywhere? I am talking about the linux-mtd intel-spi driver for example, but I feel that this gets the discussion in the wrong direction. > > > The situation is like, if you > > have that CPU, you have the hardware, so it is implicitly bound or it > > just will not execute on a machine code level. > > What do you mean "implicitly bound"? How does this tie into the driver > model such that it will only be autoloaded, and have the driver bind to > the hardware, that it knows it can control? > > That is what needs to be fixed here, you are just claiming that it can > talk to the hardware without having any check at all for this. This memory mapping is magically provided by the thing on the CPU front side bus, the south bridge f.e. It is there from the instant the system powers on and it cannot be turned off. It is the CPU reset vector that is used to boot any system. The memory range is required by the x86_64 architectural specification. Every x86_64 system out there has got it by definition. I do understand your concerns, but this thing is a very special feature of the system architecture and so the usual rules do not apply here. > > > I feel like your > > requirement is somewhat impossible to satisfy and I really don't know > > what to do. Please, can anyone help me by pointing out a proper > > example elsewhere in the kernel? > > What resource in the system describes the hardware you wish to bind to? > Write a driver for _that_ resource, and have it be properly autoloaded > when that resource is present in the system. > > You have hundreds of examples running on your system today, but as I do > not know where this hardware is described specifically, it's hard to be > able to point you to an example that works like that. > > So again, what hardware signature describes the resource you wish to > bind to? As I said above the mapping is just required to be there but it is not bound to any specific hardware. In practice every south-bridge on every x86_64 mainboard in existence provides it. It does not have any signature in a DMI table or a PCI ID or any of the like. It does not need any descriptor because it is a given thing or the system could not have booted. It is inherently tied to how the x86_64 architecture works. The only hardware dependency I can imagine there is, is that we are running on x86_64. I have checked back with other developers and they do agree. So is there a way to write a driver that is probed when we are on a certain CPU architecture and that provides me a means to hook into a probing flow where I can set up my sysfs default group to safely add the attributes to userspace? Otherwise I'd say I am sure that I understand your points and insist that the code is not broken because of the very special circumstances. Hans-Gert
