All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Asmaa Mnebhi <asmaa@nvidia.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	Khalil Blaiech <kblaiech@nvidia.com>
Subject: Re: How to remove DT support from a driver? (was Re: [PATCH v5 8/8] i2c: i2c-mlxbf.c: Update binding devicetree)
Date: Sat, 24 Sep 2022 12:31:25 -0500	[thread overview]
Message-ID: <20220924173125.GA989070-robh@kernel.org> (raw)
In-Reply-To: <Yyttt3DiQpMZYejA@shikoro>

On Wed, Sep 21, 2022 at 10:01:59PM +0200, Wolfram Sang wrote:
> Hi,
> 
> > I have a question for you and Wolfram, we don’t use device trees and
> > are not planning to use device trees; we only use ACPI tables. But I
> > think when Khalil submitted the first version of the i2c-mlxbf.c
> > driver, it was requested from him to add devicetree support. Do you
> > know why? Is it possible to remove the device tree support and so this
> > doc? or is devicetree support a requirement regardless of the actual
> > implementation? 
> 
> The first version sent from Khalil to the public I2C mailing list already
> had DT bindings [1]. I don't see a sign of someone of the public list
> requesting DT bindings. Maybe it was company internal?
> 
> Technically, there is no requirement to support DT, especially since you
> have working ACPI. I don't know the process, though, of removing DT
> support. You would basically need to be sure that no user made use of
> the DT bindings introduced before. I don't know to what degree you can
> assume that.

There's the whole using DT bindings in ACPI bindings thing, but I have 
little interest (or time) in supporting that. Maybe that's what's 
happening here? I haven't looked. The whole concept is flawed IMO. It 
may work for simple cases of key/value device properties, but the ACPI 
model is quite different in how resources are described and managed.

Rob

  parent reply	other threads:[~2022-09-24 17:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20 17:47 [PATCH v5 0/8] i2c: i2c-mlxbf.c: bug fixes and new feature support Asmaa Mnebhi
2022-09-20 17:47 ` [PATCH v5 1/8] i2c: i2c-mlxbf.c: Fix frequency calculation Asmaa Mnebhi
2022-09-21 19:44   ` Wolfram Sang
2022-09-20 17:47 ` [PATCH v5 2/8] i2c: i2c-mlxbf.c: remove IRQF_ONESHOT Asmaa Mnebhi
2022-09-20 17:47 ` [PATCH v5 3/8] i2c: i2c-mlxbf.c: incorrect base address passed during io write Asmaa Mnebhi
2022-09-20 17:47 ` [PATCH v5 4/8] i2c: i2c-mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() Asmaa Mnebhi
2022-09-20 17:47 ` [PATCH v5 5/8] i2c: i2c-mlxbf.c: support lock mechanism Asmaa Mnebhi
2022-09-20 17:47 ` [PATCH v5 6/8] i2c: i2c-mlxbf: add multi slave functionality Asmaa Mnebhi
2022-09-20 17:47 ` [PATCH v5 7/8] i2c: i2c-mlxbf.c: support BlueField-3 SoC Asmaa Mnebhi
2022-09-20 17:47 ` [PATCH v5 8/8] i2c: i2c-mlxbf.c: Update binding devicetree Asmaa Mnebhi
2022-09-21  6:55   ` Krzysztof Kozlowski
2022-09-21 13:12     ` Asmaa Mnebhi
2022-09-21 13:19       ` Krzysztof Kozlowski
2022-09-21 20:01       ` How to remove DT support from a driver? (was Re: [PATCH v5 8/8] i2c: i2c-mlxbf.c: Update binding devicetree) Wolfram Sang
2022-09-21 20:17         ` Asmaa Mnebhi
2022-09-24 17:31         ` Rob Herring [this message]
2022-09-26 13:18           ` Asmaa Mnebhi
2022-09-26 18:57             ` Wolfram Sang
2022-09-21  6:57   ` [PATCH v5 8/8] i2c: i2c-mlxbf.c: Update binding devicetree Krzysztof Kozlowski
2022-09-21  6:59   ` Krzysztof Kozlowski
2022-09-21 13:24 ` [PATCH v5 0/8] i2c: i2c-mlxbf.c: bug fixes and new feature support Asmaa Mnebhi

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=20220924173125.GA989070-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=asmaa@nvidia.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kblaiech@nvidia.com \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wsa+renesas@sang-engineering.com \
    /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.