From: ChiaWei Wang <email@example.com> To: Jeremy Kerr <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org> Cc: Morris Mao <email@example.com>, Ryan Chen <firstname.lastname@example.org> Subject: RE: [PATCH v4 3/4] soc: aspeed: Add eSPI driver Date: Thu, 2 Sep 2021 06:44:28 +0000 [thread overview] Message-ID: <HK0PR06MB37792273A075533C2570002391CE9@HK0PR06MB3779.apcprd06.prod.outlook.com> (raw) In-Reply-To: <email@example.com> Hi Jeremy, > From: Jeremy Kerr <firstname.lastname@example.org> > Sent: Thursday, September 2, 2021 11:30 AM > > Hi Chiawei, > > > The Aspeed eSPI controller is slave device to communicate with the > > master through the Enhanced Serial Peripheral Interface (eSPI). > > All of the four eSPI channels, namely peripheral, virtual wire, > > out-of-band, and flash are supported. > > I'm still not confinced this raw packet user-ABI is the right approach for this. > The four channels that you're exposing would be much more useful to use > existing kernel subsystems. The eSPI on BMC side is a slave device. Most of time it listen to the Host requests and then react. This makes it not quite fit to interfaces that act as a master role. > > Specifically: > > 1) The VW channel is essentially a GPIO interface, and we have a kernel > subsystem to expose GPIOs. We might want to add additional support > for in-kernel system event handlers, but that's a minor addition that > can be done separately if we don't want that handled by a gpio > consumer in userspace. eSPI VW channel can be used to forward a byte value to/from GPIO. However, the targeted GPIO group and its direction are determined by the Host. This is different from usual GPIO devices as it supports very limited operations. > > 2) The out-of-band (OOB) channel provides a way to issue SMBus > transactions, so could well provide an i2c controller interface. > Additionally, the eSPI specs imply that this is intended to support > MCTP - in which case, you'll *need* a kernel i2c controller device to > be able to use the new kernel MCTP stack. Could you share us more information about the i2c need of kernel MCTP kernel stack? To our understanding, the MCTP is a bus agnostic protocol. A generic raw packet interface makes it more flexible to adapt to different interfaces. > > 3) The flash channel exposes read/write/erase operations, which would be > much more useful as an actual flash-type device, perhaps using the > existing mtd interface? Or is there additional functionality > expected for this? The flash channel works in either the Master Attached Flash Sharing (MAFS) or Slave Attached Flash Sharing (SAFS) mode. For MAFS, BMC issues eSPI flash R/W/E packets to the Host. In this case, it may fit into the MTD interface. For SAFS (mostly used), BMC needs to listen, parse and filter eSPI flash R/W/E packets from the Host. And then send replies in the eSPI success/unsuccess completion packet format. This behaves differently from MTD. To support both the two scenario, the MTD interface might not be suitable. > > 4) The peripheral channel is the only one that would seem to require > arbitrary cycle access, but we'll still need a proper uapi definition > to support that. At the minimum, your ioctl definitions should go > under include/uapi/ - you shouldn't need to duplicate the header into > each userspace repo, as you've done for the test examples. In the first submission, I was told that the include/uapi patch is not going to be accepted. Thereby, I refer to other existing driver implementation which places IOCTL codes in their own driver files. In summary, considering the various applications that might be constructed upon eSPI transaction, we thought that the raw packet paradigm might be the first step to start with. Regards, Chiawei
next prev parent reply other threads:[~2021-09-02 6:45 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-01 3:30 [PATCH v4 0/4] arm: aspeed: Add eSPI support Chia-Wei Wang 2021-09-01 3:30 ` [PATCH v4 1/4] dt-bindings: aspeed: Add eSPI controller Chia-Wei Wang 2021-09-01 3:30 ` [PATCH v4 2/4] MAINTAINER: Add ASPEED eSPI driver entry Chia-Wei Wang 2021-09-01 3:30 ` [PATCH v4 3/4] soc: aspeed: Add eSPI driver Chia-Wei Wang 2021-09-02 3:29 ` Jeremy Kerr 2021-09-02 6:44 ` ChiaWei Wang [this message] 2021-09-02 7:04 ` Jeremy Kerr 2021-09-06 1:19 ` ChiaWei Wang 2021-09-06 3:16 ` Jeremy Kerr 2021-09-08 9:16 ` ChiaWei Wang 2021-09-09 1:52 ` Jeremy Kerr 2021-09-10 3:23 ` ChiaWei Wang 2021-09-01 3:30 ` [PATCH v4 4/4] ARM: dts: aspeed: Add eSPI node Chia-Wei Wang 2021-11-10 11:21 ` Andrei Kartashev 2021-11-11 1:55 ` ChiaWei Wang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=HK0PR06MB37792273A075533C2570002391CE9@HK0PR06MB3779.apcprd06.prod.outlook.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='RE: [PATCH v4 3/4] soc: aspeed: Add eSPI driver' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).