All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: linux-aspeed@lists.ozlabs.org
Subject: [Openipmi-developer] [PATCH v7 1/3] ipmi: ssif_bmc: Add SSIF BMC driver
Date: Wed, 1 Jun 2022 19:32:44 -0500	[thread overview]
Message-ID: <20220602003244.GK3767252@minyard.net> (raw)
In-Reply-To: <ba084735-0781-7ca2-4d04-a70a4115729a@os.amperecomputing.com>

On Wed, Jun 01, 2022 at 03:23:11PM +0700, Quan Nguyen wrote:
> On 04/05/2022 19:06, Corey Minyard wrote:
> > On Wed, May 04, 2022 at 01:45:03PM +0700, Quan Nguyen via Openipmi-developer wrote:
> > > > 
> > > > I seem to remember mentioning this before, but there is no reason to
> > > > pack the structures below.
> > > > 
> > > 
> > > The packed structure is because we want to pick the len directly from user
> > > space without worry about the padding byte.
> > > 
> > > As we plan not to use the .h file in next version, I still would like to use
> > > packed structure internally inside ssif_bmc.c file.
> > 
> > Packed doesn't matter for the userspace API.  If you look at other
> > structures in the userspace API, they are not packed, either.  The
> > compiler will do the right thing on both ends.
> > 
> > > 
> > > > And second, the following is a userspace API structures, so it needs to
> > > > be in its own file in include/uapi/linux, along with any supporting
> > > > things that users will need to use.  And your userspace code should be
> > > > using that file.
> > > > 
> > > 
> > > Meantime, I'd like not to use .h as I see there is no demand for sharing the
> > > data structure between kernel and user space yet. But we may do it in the
> > > future.
> > 
> > If you have a userspace API, it needs to be in include/uapi/linux.
> > You may not be the only user of this code.  In fact, you probably won't
> > be.  You need to have a .h with the structures in it, you don't want the
> > same structure in two places if you can help it.
> > 
> 
> Dear Corey,
> 
> Is it OK to push the structure definition into the
> include/uapi/linux/ipmi_bmc.h ?
> 
> Or should it need to be in separate new header file in uapi/linux ?

I think a different file, like ipmi_ssif_bmc, to match the file and
operation.  Unless you need the things in ipmi_bmc.h, which I don't
think is the case.

-corey

> 
> Thank you,
> - Quan
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Corey Minyard <minyard@acm.org>
To: Quan Nguyen <quan@os.amperecomputing.com>
Cc: devicetree@vger.kernel.org, linux-aspeed@lists.ozlabs.org,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	Andrew Jeffery <andrew@aj.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	openbmc@lists.ozlabs.org,
	"Thang Q . Nguyen" <thang@os.amperecomputing.com>,
	Brendan Higgins <brendanhiggins@google.com>,
	linux-kernel@vger.kernel.org,
	Phong Vo <phong@os.amperecomputing.com>,
	Wolfram Sang <wsa@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	openipmi-developer@lists.sourceforge.net,
	Open Source Submission <patches@amperecomputing.com>,
	linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org
Subject: Re: [Openipmi-developer] [PATCH v7 1/3] ipmi: ssif_bmc: Add SSIF BMC driver
Date: Wed, 1 Jun 2022 19:32:44 -0500	[thread overview]
Message-ID: <20220602003244.GK3767252@minyard.net> (raw)
In-Reply-To: <ba084735-0781-7ca2-4d04-a70a4115729a@os.amperecomputing.com>

On Wed, Jun 01, 2022 at 03:23:11PM +0700, Quan Nguyen wrote:
> On 04/05/2022 19:06, Corey Minyard wrote:
> > On Wed, May 04, 2022 at 01:45:03PM +0700, Quan Nguyen via Openipmi-developer wrote:
> > > > 
> > > > I seem to remember mentioning this before, but there is no reason to
> > > > pack the structures below.
> > > > 
> > > 
> > > The packed structure is because we want to pick the len directly from user
> > > space without worry about the padding byte.
> > > 
> > > As we plan not to use the .h file in next version, I still would like to use
> > > packed structure internally inside ssif_bmc.c file.
> > 
> > Packed doesn't matter for the userspace API.  If you look at other
> > structures in the userspace API, they are not packed, either.  The
> > compiler will do the right thing on both ends.
> > 
> > > 
> > > > And second, the following is a userspace API structures, so it needs to
> > > > be in its own file in include/uapi/linux, along with any supporting
> > > > things that users will need to use.  And your userspace code should be
> > > > using that file.
> > > > 
> > > 
> > > Meantime, I'd like not to use .h as I see there is no demand for sharing the
> > > data structure between kernel and user space yet. But we may do it in the
> > > future.
> > 
> > If you have a userspace API, it needs to be in include/uapi/linux.
> > You may not be the only user of this code.  In fact, you probably won't
> > be.  You need to have a .h with the structures in it, you don't want the
> > same structure in two places if you can help it.
> > 
> 
> Dear Corey,
> 
> Is it OK to push the structure definition into the
> include/uapi/linux/ipmi_bmc.h ?
> 
> Or should it need to be in separate new header file in uapi/linux ?

I think a different file, like ipmi_ssif_bmc, to match the file and
operation.  Unless you need the things in ipmi_bmc.h, which I don't
think is the case.

-corey

> 
> Thank you,
> - Quan
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Corey Minyard <minyard@acm.org>
To: Quan Nguyen <quan@os.amperecomputing.com>
Cc: devicetree@vger.kernel.org, linux-aspeed@lists.ozlabs.org,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	Andrew Jeffery <andrew@aj.id.au>,
	openbmc@lists.ozlabs.org,
	"Thang Q . Nguyen" <thang@os.amperecomputing.com>,
	Brendan Higgins <brendanhiggins@google.com>,
	linux-kernel@vger.kernel.org,
	Phong Vo <phong@os.amperecomputing.com>,
	Wolfram Sang <wsa@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	linux-i2c@vger.kernel.org,
	openipmi-developer@lists.sourceforge.net,
	Open Source Submission <patches@amperecomputing.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Openipmi-developer] [PATCH v7 1/3] ipmi: ssif_bmc: Add SSIF BMC driver
Date: Wed, 1 Jun 2022 19:32:44 -0500	[thread overview]
Message-ID: <20220602003244.GK3767252@minyard.net> (raw)
In-Reply-To: <ba084735-0781-7ca2-4d04-a70a4115729a@os.amperecomputing.com>

On Wed, Jun 01, 2022 at 03:23:11PM +0700, Quan Nguyen wrote:
> On 04/05/2022 19:06, Corey Minyard wrote:
> > On Wed, May 04, 2022 at 01:45:03PM +0700, Quan Nguyen via Openipmi-developer wrote:
> > > > 
> > > > I seem to remember mentioning this before, but there is no reason to
> > > > pack the structures below.
> > > > 
> > > 
> > > The packed structure is because we want to pick the len directly from user
> > > space without worry about the padding byte.
> > > 
> > > As we plan not to use the .h file in next version, I still would like to use
> > > packed structure internally inside ssif_bmc.c file.
> > 
> > Packed doesn't matter for the userspace API.  If you look at other
> > structures in the userspace API, they are not packed, either.  The
> > compiler will do the right thing on both ends.
> > 
> > > 
> > > > And second, the following is a userspace API structures, so it needs to
> > > > be in its own file in include/uapi/linux, along with any supporting
> > > > things that users will need to use.  And your userspace code should be
> > > > using that file.
> > > > 
> > > 
> > > Meantime, I'd like not to use .h as I see there is no demand for sharing the
> > > data structure between kernel and user space yet. But we may do it in the
> > > future.
> > 
> > If you have a userspace API, it needs to be in include/uapi/linux.
> > You may not be the only user of this code.  In fact, you probably won't
> > be.  You need to have a .h with the structures in it, you don't want the
> > same structure in two places if you can help it.
> > 
> 
> Dear Corey,
> 
> Is it OK to push the structure definition into the
> include/uapi/linux/ipmi_bmc.h ?
> 
> Or should it need to be in separate new header file in uapi/linux ?

I think a different file, like ipmi_ssif_bmc, to match the file and
operation.  Unless you need the things in ipmi_bmc.h, which I don't
think is the case.

-corey

> 
> Thank you,
> - Quan
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Corey Minyard <minyard@acm.org>
To: Quan Nguyen <quan@os.amperecomputing.com>
Cc: devicetree@vger.kernel.org, linux-aspeed@lists.ozlabs.org,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	Andrew Jeffery <andrew@aj.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	openbmc@lists.ozlabs.org,
	"Thang Q . Nguyen" <thang@os.amperecomputing.com>,
	Brendan Higgins <brendanhiggins@google.com>,
	linux-kernel@vger.kernel.org,
	Phong Vo <phong@os.amperecomputing.com>,
	Wolfram Sang <wsa@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	openipmi-developer@lists.sourceforge.net,
	Open Source Submission <patches@amperecomputing.com>,
	linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org
Subject: Re: [Openipmi-developer] [PATCH v7 1/3] ipmi: ssif_bmc: Add SSIF BMC driver
Date: Wed, 1 Jun 2022 19:32:44 -0500	[thread overview]
Message-ID: <20220602003244.GK3767252@minyard.net> (raw)
In-Reply-To: <ba084735-0781-7ca2-4d04-a70a4115729a@os.amperecomputing.com>

On Wed, Jun 01, 2022 at 03:23:11PM +0700, Quan Nguyen wrote:
> On 04/05/2022 19:06, Corey Minyard wrote:
> > On Wed, May 04, 2022 at 01:45:03PM +0700, Quan Nguyen via Openipmi-developer wrote:
> > > > 
> > > > I seem to remember mentioning this before, but there is no reason to
> > > > pack the structures below.
> > > > 
> > > 
> > > The packed structure is because we want to pick the len directly from user
> > > space without worry about the padding byte.
> > > 
> > > As we plan not to use the .h file in next version, I still would like to use
> > > packed structure internally inside ssif_bmc.c file.
> > 
> > Packed doesn't matter for the userspace API.  If you look at other
> > structures in the userspace API, they are not packed, either.  The
> > compiler will do the right thing on both ends.
> > 
> > > 
> > > > And second, the following is a userspace API structures, so it needs to
> > > > be in its own file in include/uapi/linux, along with any supporting
> > > > things that users will need to use.  And your userspace code should be
> > > > using that file.
> > > > 
> > > 
> > > Meantime, I'd like not to use .h as I see there is no demand for sharing the
> > > data structure between kernel and user space yet. But we may do it in the
> > > future.
> > 
> > If you have a userspace API, it needs to be in include/uapi/linux.
> > You may not be the only user of this code.  In fact, you probably won't
> > be.  You need to have a .h with the structures in it, you don't want the
> > same structure in two places if you can help it.
> > 
> 
> Dear Corey,
> 
> Is it OK to push the structure definition into the
> include/uapi/linux/ipmi_bmc.h ?
> 
> Or should it need to be in separate new header file in uapi/linux ?

I think a different file, like ipmi_ssif_bmc, to match the file and
operation.  Unless you need the things in ipmi_bmc.h, which I don't
think is the case.

-corey

> 
> Thank you,
> - Quan
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-06-02  0:32 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-22  4:08 [PATCH v7 0/3] Add SSIF BMC driver Quan Nguyen
2022-04-22  4:08 ` Quan Nguyen
2022-04-22  4:08 ` Quan Nguyen
2022-04-22  4:08 ` Quan Nguyen
2022-04-22  4:08 ` [PATCH v7 1/3] ipmi: ssif_bmc: " Quan Nguyen
2022-04-22  4:08   ` Quan Nguyen
2022-04-22  4:08   ` Quan Nguyen
2022-04-22  4:08   ` Quan Nguyen
2022-04-22  4:16   ` Quan Nguyen
2022-04-22  4:16     ` Quan Nguyen
2022-04-22  4:16     ` Quan Nguyen
2022-04-22  4:16     ` Quan Nguyen
2022-04-23  1:51   ` Corey Minyard
2022-04-23  1:51     ` Corey Minyard
2022-04-23  1:51     ` Corey Minyard
2022-04-23  1:51     ` Corey Minyard
2022-05-04  6:45     ` Quan Nguyen
2022-05-04  6:45       ` Quan Nguyen
2022-05-04  6:45       ` Quan Nguyen
2022-05-04  6:45       ` Quan Nguyen
2022-05-04 12:06       ` [Openipmi-developer] " Corey Minyard
2022-05-04 12:06         ` Corey Minyard
2022-05-04 12:06         ` Corey Minyard
2022-05-04 12:06         ` Corey Minyard
2022-06-01  8:23         ` Quan Nguyen
2022-06-01  8:23           ` Quan Nguyen
2022-06-01  8:23           ` Quan Nguyen
2022-06-01  8:23           ` Quan Nguyen
2022-06-02  0:32           ` Corey Minyard [this message]
2022-06-02  0:32             ` Corey Minyard
2022-06-02  0:32             ` Corey Minyard
2022-06-02  0:32             ` Corey Minyard
2022-06-02  9:38             ` Quan Nguyen
2022-06-02  9:38               ` Quan Nguyen
2022-06-02  9:38               ` Quan Nguyen
2022-06-02  9:38               ` Quan Nguyen
2022-04-22  4:08 ` [PATCH v7 2/3] bindings: ipmi: Add binding for " Quan Nguyen
2022-04-22  4:08   ` Quan Nguyen
2022-04-22  4:08   ` Quan Nguyen
2022-04-22  4:08   ` Quan Nguyen
2022-04-22  4:16   ` Quan Nguyen
2022-04-22  4:16     ` Quan Nguyen
2022-04-22  4:16     ` Quan Nguyen
2022-04-22  4:16     ` Quan Nguyen
2022-04-22  7:21     ` Krzysztof Kozlowski
2022-04-22  7:21       ` Krzysztof Kozlowski
2022-04-22  7:21       ` Krzysztof Kozlowski
2022-04-22  7:56       ` Quan Nguyen
2022-04-22  7:56         ` Quan Nguyen
2022-04-22  7:56         ` Quan Nguyen
2022-04-22  7:56         ` Quan Nguyen
2022-04-25 21:39   ` Rob Herring
2022-04-25 21:39     ` Rob Herring
2022-04-25 21:39     ` Rob Herring
2022-04-25 21:39     ` Rob Herring
2022-04-22  4:08 ` [PATCH v7 3/3] i2c: aspeed: Assert NAK when slave is busy Quan Nguyen
2022-04-22  4:08   ` Quan Nguyen
2022-04-22  4:08   ` Quan Nguyen
2022-04-22  4:08   ` Quan Nguyen
2022-04-22  4:17   ` Quan Nguyen
2022-04-22  4:17     ` Quan Nguyen
2022-04-22  4:17     ` Quan Nguyen
2022-04-22  4:17     ` Quan Nguyen
2022-05-14 14:31   ` Wolfram Sang
2022-05-14 14:31     ` Wolfram Sang
2022-05-14 14:31     ` Wolfram Sang
2022-05-14 14:31     ` Wolfram Sang
2022-05-16  2:32     ` Quan Nguyen
2022-05-16  2:32       ` Quan Nguyen
2022-05-16  2:32       ` Quan Nguyen
2022-06-15 20:32       ` Wolfram Sang
2022-06-15 20:32         ` Wolfram Sang
2022-06-15 20:32         ` Wolfram Sang
2022-06-15 20:32         ` Wolfram Sang
2022-06-16  7:16         ` Quan Nguyen
2022-06-16  7:16           ` Quan Nguyen
2022-06-16  7:16           ` Quan Nguyen
2022-06-16 12:29           ` Wolfram Sang
2022-06-16 12:29             ` Wolfram Sang
2022-06-16 12:29             ` Wolfram Sang
2022-06-16 12:29             ` Wolfram Sang
2022-06-17  7:08             ` Quan Nguyen
2022-06-17  7:08               ` Quan Nguyen
2022-06-17  7:08               ` Quan Nguyen
2022-07-05  2:45               ` Quan Nguyen
2022-07-05  2:45                 ` Quan Nguyen
2022-07-05  2:45                 ` Quan Nguyen
2022-04-22  4:16 ` [PATCH v7 0/3] Add SSIF BMC driver Quan Nguyen
2022-04-22  4:16   ` Quan Nguyen
2022-04-22  4:16   ` Quan Nguyen
2022-04-22  4:16   ` Quan Nguyen

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=20220602003244.GK3767252@minyard.net \
    --to=minyard@acm.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.