Message-ID: <CAH9NwWfZQ5G798vYOw3gVa4WBsBSmcjLKONG3u9SiAtwf5wdNg@mail.gmail.com>
Date: Tue, 20 Aug 2024 10:48:06 +0200
From: Christian Gmeiner <christian.gmeiner@...il.com>
To: Thomas Richard <thomas.richard@...tlin.com>
Cc: Mary Strodl <mstrodl@....rit.edu>, linux-kernel@...r.kernel.org, 
	akpm@...ux-foundation.org, urezki@...il.com, hch@...radead.org, 
	linux-mm@...ck.org, lee@...nel.org, andi.shyti@...nel.org, 
	linux-i2c@...r.kernel.org, s.hauer@...gutronix.de, 
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v4 0/2] Add support for Congatec CGEB BIOS interface

Hi Thomas!

>
> On 8/14/24 20:47, Mary Strodl wrote:
> > The following series adds support for the Congatec CGEB interface
> > found on some Congatec x86 boards. The CGEB interface is a BIOS
> > interface which provides access to onboard peripherals like I2C
> > busses and watchdogs. It works by mapping BIOS code and searching
> > for magic values which specify the entry points to the CGEB call.
> > The CGEB call is an API provided by the BIOS which provides access
> > to the functions in an ioctl like fashion.
> >
> > At the request of some folks the first time I sent this series out,
> > CGEB has a userspace component which runs the x86 blob (rather than
> > running it directly in the kernel), which sends requests back and
> > forth using the cn_netlink API.
> >
> > You can find a reference implementation of the userspace helper here:
> > https://github.com/Mstrodl/cgeb-helper
> >
> > I didn't get an answer when I asked where the userspace component
> > should live, so I didn't put a ton of work into getting the helper
> > up to snuff since similar userspace helpers (like v86d) are not
> > in-tree. If folks would like the helper in-tree, that's fine too.
>
> Hello Mary !!
>
> It was by pure luck that I found your series.
>
> It seems we are working on the same thing, the Congatec Board Controller.
>
> I sent a first version of my series few weeks ago [1].
> My implementation is very different.
> There is an MFD which maps the needed IO regions and declares cells
> (gpio, watchdog, i2c). It also contains all the code to communicate with
> the Board Controller (using ioread and iowrite).
> The DMI table is used to detect if the board is supported, so the driver
> can be probed (or not).
> Other drivers (gpio, i2c and watchdog for now) use the API provided by
> the MFD to communicate with the Board Controller.
> With this approach, I don't need a userspace component.
>
> For this work I used the Congatec driver (that Thomas Gleixner pointed
> you) as reference. But as mentioned by Thomas the driver is not well
> written at all.
> By the way their latest version is available in their yocto metalayer
> (please find the link in my series).
>

I'm glad to see that Congatec has taken a different approach with
their driver and
is no longer relying on the BIOS blob method. Years ago, I shared my
frustrations
with them over this outdated solution through numerous phone calls,
but the company
I worked for was simply too small to have any real influence.

> For now I did the job for the conga-SA7 board (which has a 5th
> generation Board Controller).
> So if you have hardware which has the same generation of the Board
> Controller, you can easily test the series. You only need to add the DMI
> entry of your board in the MFD driver.
>
> For other generations, I had a quick look. The sequences seem very
> similar, with minor differences. It could be easily implemented in the
> future, and only the MFD will be modified.
>

Fantastic news - looks like all the pain with this board controller
under Linux is gone soon.

-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info/privacypolicy

Powered by blists - more mailing lists