Message-ID: <CAHifhD6K5hbpHS-X+2L=pfUe+7OpyTbB7uyh8WGbdaeBMwoYPg@mail.gmail.com>
Date:   Tue, 9 Nov 2021 15:10:15 +0100
From:   Hans-Gert Dahmen <hans-gert.dahmen@...u.ne>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
        Philipp Deppenwiese <philipp.deppenwiese@...u.ne>,
        Mauro Lima <mauro.lima@...ypsium.com>,
        Richard Hughes <hughsient@...il.com>,
        platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH] firmware: export x86_64 platform flash bios region via sysfs

Am Di., 9. Nov. 2021 um 13:42 Uhr schrieb Greg KH <gregkh@...uxfoundation.org>:
> ...
>
> 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

Powered by blists - more mailing lists