Received-SPF: pass (google.com: domain of linux-kernel+bounces-78551-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Fri, 23 Feb 2024 16:54:54 +0200
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Saravana Kannan <saravanak@google.com>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
	Linus Walleij <linus.walleij@linaro.org>,
	Kent Gibson <warthog618@gmail.com>, linux-gpio@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
	Android Kernel Team <kernel-team@android.com>
Subject: Re: [PATCH] gpio: sim: don't fiddle with GPIOLIB private members
Message-ID: <ZdixvgZaW0-95zc8@smile.fi.intel.com>
References: <ZPWcTMPiu4MSq+F7@smile.fi.intel.com>
 <CAMRc=MfZv70FXHyNw4yK90NL5-jjAJa6qbKc6SV2ZwbaJkKQqg@mail.gmail.com>
 <ZPWmDL6QJJMNi2qa@smile.fi.intel.com>
 <CAMRc=Mc0JgPUEpaes7WcbkMu5JyrpLW8N1+bM-+OJaB+pPX4ew@mail.gmail.com>
 <ZPWr3dRP5C1GSY9F@smile.fi.intel.com>
 <CAMRc=Mfae+=HPPWzsG8bgK2CGOGY9GPkS5VZcwLyr_yY8A_y2g@mail.gmail.com>
 <ZPWxbfHNOqAnkR09@smile.fi.intel.com>
 <CAGETcx9wERf-R4=r_jBYpYgGHSxS=-xx_ydeVWZdGUvEWTQwzg@mail.gmail.com>
 <ZdXzxY3-g7oY00Mq@smile.fi.intel.com>
 <CAGETcx92GgwBpd58dLgquLFxqXiHK5QHGK3Rhkd9pC_4p7Ra6w@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAGETcx92GgwBpd58dLgquLFxqXiHK5QHGK3Rhkd9pC_4p7Ra6w@mail.gmail.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

On Thu, Feb 22, 2024 at 05:01:04PM -0800, Saravana Kannan wrote:
> On Wed, Feb 21, 2024 at 4:59 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Feb 20, 2024 at 05:46:27PM -0800, Saravana Kannan wrote:

..

> > Is there any _good_ documentation for devlinks and all that fields in the
> > struct fwnode? Why should we use that without any understanding of the
> > purposes of that field. We, as device property developers, hadn't introduced
> > that field and never required it. It's an alien to device properties APIs.
> 
> If I add some inline documentation for these fields, will you be more
> open to letting people use this as a way to look up devices? I'm happy
> to do that for you.

I consider documentation patches to be always welcome. But it doesn't mean
we allow to use that fields in device property APIs without a very good
justification.

-- 
With Best Regards,
Andy Shevchenko