All of lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: linux-aspeed@lists.ozlabs.org
Subject: 回覆: [PATCH] Add eSPI device driver (flash channel)
Date: Thu, 15 Feb 2024 17:12:50 +0000	[thread overview]
Message-ID: <20240215-probable-gimmick-83d5dcbc4729@spud> (raw)
In-Reply-To: <TYZPR06MB6640F82C539F0B17BCDCC55E914D2@TYZPR06MB6640.apcprd06.prod.outlook.com>

On Thu, Feb 15, 2024 at 01:56:00AM +0000, ChiaWei Wang wrote:
> > 
> > On Wed, Feb 14, 2024 at 11:34:31AM +0000, ChiaWei Wang wrote:
> > > We appreciate that you are willing to help on the open source contribution.
> > > However, please co-work with Aspeed before submitting drivers of Aspeed
> > HW.
> > > Otherwise, a misleading driver on the community are going to bring tons of
> > customer issues to Aspeed.
> > 
> > It may not apply in this particular case as Aspeed did write the original driver
> > and it is polite to work with previous authors when respinning a patchset, but in
> > general there is no need to work with a hardware vendor before writing drivers
> > for their hardware.
> > 
> > Blocking a driver because that company might receive more support requests
> > is not the kernel's problem.
> 
> I agree with that and Aspeed will not refuse to support.
> 
> However, in this case, the authors, IBM, and Aspeed already have discussion (at least 4 times) before and foresee "issues" on practical eSPI SAFS use.
> If there is already a known issue of the driver, why ignoring the previous discussion and push it?
> A compromise is to ask for driver renaming to espi-mafs to avoid confusion.
> Otherwise we need to explain, again, why the driver does not fulfill the SAFS expectation.

To be clear, in case you misunderstood, I was making a general point and
not about this particular patchset.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20240215/21edebee/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: ChiaWei Wang <chiawei_wang@aspeedtech.com>
Cc: Manojkiran Eda <manojkiran.eda@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, Joel Stanley <joel@jms.id.au>,
	Andrew Jeffery <andrew@codeconstruct.com.au>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	"jk@codeconstruct.com.au" <jk@codeconstruct.com.au>,
	Patrick Rudolph <patrick.rudolph@9elements.com>,
	Ryan Chen <ryan_chen@aspeedtech.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"zev@bewilderbeest.net" <zev@bewilderbeest.net>
Subject: Re: 回覆: [PATCH] Add eSPI device driver (flash channel)
Date: Thu, 15 Feb 2024 17:12:50 +0000	[thread overview]
Message-ID: <20240215-probable-gimmick-83d5dcbc4729@spud> (raw)
In-Reply-To: <TYZPR06MB6640F82C539F0B17BCDCC55E914D2@TYZPR06MB6640.apcprd06.prod.outlook.com>


[-- Attachment #1.1: Type: text/plain, Size: 1439 bytes --]

On Thu, Feb 15, 2024 at 01:56:00AM +0000, ChiaWei Wang wrote:
> > 
> > On Wed, Feb 14, 2024 at 11:34:31AM +0000, ChiaWei Wang wrote:
> > > We appreciate that you are willing to help on the open source contribution.
> > > However, please co-work with Aspeed before submitting drivers of Aspeed
> > HW.
> > > Otherwise, a misleading driver on the community are going to bring tons of
> > customer issues to Aspeed.
> > 
> > It may not apply in this particular case as Aspeed did write the original driver
> > and it is polite to work with previous authors when respinning a patchset, but in
> > general there is no need to work with a hardware vendor before writing drivers
> > for their hardware.
> > 
> > Blocking a driver because that company might receive more support requests
> > is not the kernel's problem.
> 
> I agree with that and Aspeed will not refuse to support.
> 
> However, in this case, the authors, IBM, and Aspeed already have discussion (at least 4 times) before and foresee "issues" on practical eSPI SAFS use.
> If there is already a known issue of the driver, why ignoring the previous discussion and push it?
> A compromise is to ask for driver renaming to espi-mafs to avoid confusion.
> Otherwise we need to explain, again, why the driver does not fulfill the SAFS expectation.

To be clear, in case you misunderstood, I was making a general point and
not about this particular patchset.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: ChiaWei Wang <chiawei_wang@aspeedtech.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	"zev@bewilderbeest.net" <zev@bewilderbeest.net>,
	Ryan Chen <ryan_chen@aspeedtech.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	Richard Weinberger <richard@nod.at>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Joel Stanley <joel@jms.id.au>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	"jk@codeconstruct.com.au" <jk@codeconstruct.com.au>,
	Patrick Rudolph <patrick.rudolph@9elements.com>,
	Manojkiran Eda <manojkiran.eda@gmail.com>
Subject: Re: 回覆: [PATCH] Add eSPI device driver (flash channel)
Date: Thu, 15 Feb 2024 17:12:50 +0000	[thread overview]
Message-ID: <20240215-probable-gimmick-83d5dcbc4729@spud> (raw)
In-Reply-To: <TYZPR06MB6640F82C539F0B17BCDCC55E914D2@TYZPR06MB6640.apcprd06.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

On Thu, Feb 15, 2024 at 01:56:00AM +0000, ChiaWei Wang wrote:
> > 
> > On Wed, Feb 14, 2024 at 11:34:31AM +0000, ChiaWei Wang wrote:
> > > We appreciate that you are willing to help on the open source contribution.
> > > However, please co-work with Aspeed before submitting drivers of Aspeed
> > HW.
> > > Otherwise, a misleading driver on the community are going to bring tons of
> > customer issues to Aspeed.
> > 
> > It may not apply in this particular case as Aspeed did write the original driver
> > and it is polite to work with previous authors when respinning a patchset, but in
> > general there is no need to work with a hardware vendor before writing drivers
> > for their hardware.
> > 
> > Blocking a driver because that company might receive more support requests
> > is not the kernel's problem.
> 
> I agree with that and Aspeed will not refuse to support.
> 
> However, in this case, the authors, IBM, and Aspeed already have discussion (at least 4 times) before and foresee "issues" on practical eSPI SAFS use.
> If there is already a known issue of the driver, why ignoring the previous discussion and push it?
> A compromise is to ask for driver renaming to espi-mafs to avoid confusion.
> Otherwise we need to explain, again, why the driver does not fulfill the SAFS expectation.

To be clear, in case you misunderstood, I was making a general point and
not about this particular patchset.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: ChiaWei Wang <chiawei_wang@aspeedtech.com>
Cc: Manojkiran Eda <manojkiran.eda@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, Joel Stanley <joel@jms.id.au>,
	Andrew Jeffery <andrew@codeconstruct.com.au>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	"jk@codeconstruct.com.au" <jk@codeconstruct.com.au>,
	Patrick Rudolph <patrick.rudolph@9elements.com>,
	Ryan Chen <ryan_chen@aspeedtech.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"zev@bewilderbeest.net" <zev@bewilderbeest.net>
Subject: Re: 回覆: [PATCH] Add eSPI device driver (flash channel)
Date: Thu, 15 Feb 2024 17:12:50 +0000	[thread overview]
Message-ID: <20240215-probable-gimmick-83d5dcbc4729@spud> (raw)
In-Reply-To: <TYZPR06MB6640F82C539F0B17BCDCC55E914D2@TYZPR06MB6640.apcprd06.prod.outlook.com>


[-- Attachment #1.1: Type: text/plain, Size: 1439 bytes --]

On Thu, Feb 15, 2024 at 01:56:00AM +0000, ChiaWei Wang wrote:
> > 
> > On Wed, Feb 14, 2024 at 11:34:31AM +0000, ChiaWei Wang wrote:
> > > We appreciate that you are willing to help on the open source contribution.
> > > However, please co-work with Aspeed before submitting drivers of Aspeed
> > HW.
> > > Otherwise, a misleading driver on the community are going to bring tons of
> > customer issues to Aspeed.
> > 
> > It may not apply in this particular case as Aspeed did write the original driver
> > and it is polite to work with previous authors when respinning a patchset, but in
> > general there is no need to work with a hardware vendor before writing drivers
> > for their hardware.
> > 
> > Blocking a driver because that company might receive more support requests
> > is not the kernel's problem.
> 
> I agree with that and Aspeed will not refuse to support.
> 
> However, in this case, the authors, IBM, and Aspeed already have discussion (at least 4 times) before and foresee "issues" on practical eSPI SAFS use.
> If there is already a known issue of the driver, why ignoring the previous discussion and push it?
> A compromise is to ask for driver renaming to espi-mafs to avoid confusion.
> Otherwise we need to explain, again, why the driver does not fulfill the SAFS expectation.

To be clear, in case you misunderstood, I was making a general point and
not about this particular patchset.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: ChiaWei Wang <chiawei_wang@aspeedtech.com>
Cc: Manojkiran Eda <manojkiran.eda@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, Joel Stanley <joel@jms.id.au>,
	Andrew Jeffery <andrew@codeconstruct.com.au>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	"jk@codeconstruct.com.au" <jk@codeconstruct.com.au>,
	Patrick Rudolph <patrick.rudolph@9elements.com>,
	Ryan Chen <ryan_chen@aspeedtech.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"zev@bewilderbeest.net" <zev@bewilderbeest.net>
Subject: Re: 回覆: [PATCH] Add eSPI device driver (flash channel)
Date: Thu, 15 Feb 2024 17:12:50 +0000	[thread overview]
Message-ID: <20240215-probable-gimmick-83d5dcbc4729@spud> (raw)
In-Reply-To: <TYZPR06MB6640F82C539F0B17BCDCC55E914D2@TYZPR06MB6640.apcprd06.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

On Thu, Feb 15, 2024 at 01:56:00AM +0000, ChiaWei Wang wrote:
> > 
> > On Wed, Feb 14, 2024 at 11:34:31AM +0000, ChiaWei Wang wrote:
> > > We appreciate that you are willing to help on the open source contribution.
> > > However, please co-work with Aspeed before submitting drivers of Aspeed
> > HW.
> > > Otherwise, a misleading driver on the community are going to bring tons of
> > customer issues to Aspeed.
> > 
> > It may not apply in this particular case as Aspeed did write the original driver
> > and it is polite to work with previous authors when respinning a patchset, but in
> > general there is no need to work with a hardware vendor before writing drivers
> > for their hardware.
> > 
> > Blocking a driver because that company might receive more support requests
> > is not the kernel's problem.
> 
> I agree with that and Aspeed will not refuse to support.
> 
> However, in this case, the authors, IBM, and Aspeed already have discussion (at least 4 times) before and foresee "issues" on practical eSPI SAFS use.
> If there is already a known issue of the driver, why ignoring the previous discussion and push it?
> A compromise is to ask for driver renaming to espi-mafs to avoid confusion.
> Otherwise we need to explain, again, why the driver does not fulfill the SAFS expectation.

To be clear, in case you misunderstood, I was making a general point and
not about this particular patchset.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2024-02-15 17:12 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-13 14:36 [PATCH] Add eSPI device driver (flash channel) Manojkiran Eda
2024-02-13 14:36 ` Manojkiran Eda
2024-02-13 14:36 ` Manojkiran Eda
2024-02-13 14:36 ` Manojkiran Eda
2024-02-13 14:36 ` Manojkiran Eda
2024-02-13 15:40 ` Rob Herring
2024-02-13 15:40   ` Rob Herring
2024-02-13 15:40   ` Rob Herring
2024-02-13 15:40   ` Rob Herring
2024-02-13 15:40   ` Rob Herring
2024-02-13 22:28 ` Rob Herring
2024-02-13 22:28   ` Rob Herring
2024-02-13 22:28   ` Rob Herring
2024-02-13 22:28   ` Rob Herring
2024-02-13 22:28   ` Rob Herring
2024-02-14  9:53 ` Krzysztof Kozlowski
2024-02-14  9:53   ` Krzysztof Kozlowski
2024-02-14  9:53   ` Krzysztof Kozlowski
2024-02-14  9:53   ` Krzysztof Kozlowski
2024-02-14 11:34 ` 回覆: " ChiaWei Wang
2024-02-14 11:34   ` ChiaWei Wang
2024-02-14 11:34   ` ChiaWei Wang
2024-02-14 11:34   ` ChiaWei Wang
2024-02-14 11:34   ` ChiaWei Wang
2024-02-14 18:31   ` Conor Dooley
2024-02-14 18:31     ` Conor Dooley
2024-02-14 18:31     ` Conor Dooley
2024-02-14 18:31     ` Conor Dooley
2024-02-14 18:31     ` Conor Dooley
2024-02-15  1:56     ` ChiaWei Wang
2024-02-15  1:56       ` ChiaWei Wang
2024-02-15  1:56       ` ChiaWei Wang
2024-02-15  1:56       ` ChiaWei Wang
2024-02-15  1:56       ` ChiaWei Wang
2024-02-15 17:12       ` Conor Dooley [this message]
2024-02-15 17:12         ` Conor Dooley
2024-02-15 17:12         ` Conor Dooley
2024-02-15 17:12         ` Conor Dooley
2024-02-15 17:12         ` Conor Dooley
2024-02-18  9:36         ` ChiaWei Wang
2024-02-18  9:36           ` ChiaWei Wang
2024-02-18  9:36           ` ChiaWei Wang
2024-02-18  9:36           ` ChiaWei Wang
2024-02-18  9:36           ` ChiaWei Wang
2024-02-16 10:20 ` Zev Weiss
2024-02-16 10:20   ` Zev Weiss
2024-02-16 10:20   ` Zev Weiss
2024-02-16 10:20   ` Zev Weiss
2024-02-16 10:20   ` Zev Weiss

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=20240215-probable-gimmick-83d5dcbc4729@spud \
    --to=conor@kernel.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.