Re: [v5 3/5] dt-bindings: mfd: Add aspeed pwm-tach binding

From: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Billy Tsai <billy_tsai@aspeedtech.com>
Cc: Patrick Williams <patrick@stwcx.xyz>,
	jdelvare@suse.com, linux@roeck-us.net,
	krzysztof.kozlowski+dt@linaro.org, joel@jms.id.au,
	andrew@aj.id.au, lee@kernel.org, thierry.reding@gmail.com,
	u.kleine-koenig@pengutronix.de, corbet@lwn.net,
	p.zabel@pengutronix.de, linux-hwmon@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	linux-pwm@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [v5 3/5] dt-bindings: mfd: Add aspeed pwm-tach binding
Date: Thu, 8 Jun 2023 09:15:52 -0600	[thread overview]
Message-ID: <20230608151552.GA2637361-robh@kernel.org> (raw)
In-Reply-To: <c28f963e-d13c-6b5c-c389-996e986f81d5@linaro.org>

On Tue, Jun 06, 2023 at 04:23:52PM +0200, Krzysztof Kozlowski wrote:
> On 06/06/2023 16:06, Patrick Williams wrote:
> > On Tue, Jun 06, 2023 at 12:49:04PM +0200, Krzysztof Kozlowski wrote:
> > 
> > Hi Krzysztof,
> > 
> > Thank you for reviewing this from Billy.
> > 
> > The Aspeed chip is heavily used by the OpenBMC community and the 2600
> > has been used in production systems for almost 2 years now.  Many
> > companies are having to carry previous versions of these as patches, and
> > some of the APIs changed since the last revision from Billy.  So, I had
> > asked him to submit the latest patch set with as many revisions as he
> > understood what to change, since the conversation seemed to have died
> > since last time he submitted.  
> > 
> > I don't believe Billy is intentionally ignoring your feedback and he is
> > motivated to get this patch set wrapped up into an acceptable state.
> > 
> >> On 06/06/2023 11:45, Billy Tsai wrote:
> >  
> >> NAK. You got here clear comment. You cannot have simple MFD with
> >> resources. It is not simple anymore.
> >>
> > 
> > In fairness, Billy asked for clarification from you on this point and didn't
> > receive it.
> > 
> > https://lore.kernel.org/lkml/24DD1FEB-95F3-47BE-BE61-8B0E6FBDE20F@aspeedtech.com/
> 
> I gave the instruction what Billy should do:
> 
> https://lore.kernel.org/lkml/41500a04-b004-0e2c-20a1-3a3092b90e6d@linaro.org/
> 
> What about other ignored comments? About subject, quotes and more? Even
> if this one was unclear, then why ignoring all the rest?
> 
> > 
> > He felt what he was trying to accomplish met the documented
> > expectations.  Are there some changes that need to be done in mfd.txt to
> > further clarify when to use it and when not to?
> 
> I think mfd.txt clearly states:
> "For more complex devices, when the nexus driver has to
> probe registers to figure out what child devices exist etc, this should
> not be used. In the latter case the child devices will be determined by
> the operating system."
> 
> Also, repeated many times:
> https://lore.kernel.org/all/YXhINE00HG6hbQI4@robh.at.kernel.org/
> https://lore.kernel.org/all/20220701000959.GA3588170-robh@kernel.org/
> https://osseu2022.sched.com/event/15z0W

I've probably said this already, but any 'fan controller' needs to 
define a common fan binding that works for multiple scenarios. There's 
been some attempts in the last year which seems to have stalled out.

Rob

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