All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: "Paweł Anikiel" <pan@semihalf.com>
Cc: jarkko.nikula@linux.intel.com, mika.westerberg@linux.intel.com,
	robh+dt@kernel.org, p.zabel@pengutronix.de, arnd@arndb.de,
	olof@lixom.net, soc@kernel.org, dinguyen@kernel.org,
	p.yadav@ti.com, Tudor.Ambarus@microchip.com,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	alexandre.belloni@bootlin.com, sre@kernel.org,
	thunder.leizhen@huawei.com, Jonathan.Cameron@huawei.com,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	ka@semihalf.com, tn@semihalf.com, jam@semihalf.com,
	amstan@google.com
Subject: Re: [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller
Date: Tue, 5 Oct 2021 19:19:57 +0300	[thread overview]
Message-ID: <YVx7LdKo1f1KBpqr@smile.fi.intel.com> (raw)
In-Reply-To: <20211005143748.2471647-2-pan@semihalf.com>

On Tue, Oct 05, 2021 at 04:37:45PM +0200, Paweł Anikiel wrote:
> On SoCFPGA systems, it's desireable to have fixed numbering for
> i2c busses, while being able to enable/disable them (e.g. have i2c1
> be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also
> be achieved using devicetree aliases (see i2c_add_adapter). However,
> having the driver be self-contained without relying on aliases is more
> robust.

Why? This number means nothing, user space has another means to have
this being robust. Sorry, but I don't see any even close to good enough
justification, NAK.

-- 
With Best Regards,
Andy Shevchenko



WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: "Paweł Anikiel" <pan@semihalf.com>
Cc: jarkko.nikula@linux.intel.com, mika.westerberg@linux.intel.com,
	robh+dt@kernel.org, p.zabel@pengutronix.de, arnd@arndb.de,
	olof@lixom.net, soc@kernel.org, dinguyen@kernel.org,
	p.yadav@ti.com, Tudor.Ambarus@microchip.com,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	alexandre.belloni@bootlin.com, sre@kernel.org,
	thunder.leizhen@huawei.com, Jonathan.Cameron@huawei.com,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	ka@semihalf.com, tn@semihalf.com, jam@semihalf.com,
	amstan@google.com
Subject: Re: [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller
Date: Tue, 5 Oct 2021 19:19:57 +0300	[thread overview]
Message-ID: <YVx7LdKo1f1KBpqr@smile.fi.intel.com> (raw)
Message-ID: <20211005161957.T5wmze4erQwVaJ_Qz6HuYpG-tazZVAsCNsrUKO-yStE@z> (raw)
In-Reply-To: <20211005143748.2471647-2-pan@semihalf.com>

On Tue, Oct 05, 2021 at 04:37:45PM +0200, Paweł Anikiel wrote:
> On SoCFPGA systems, it's desireable to have fixed numbering for
> i2c busses, while being able to enable/disable them (e.g. have i2c1
> be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also
> be achieved using devicetree aliases (see i2c_add_adapter). However,
> having the driver be self-contained without relying on aliases is more
> robust.

Why? This number means nothing, user space has another means to have
this being robust. Sorry, but I don't see any even close to good enough
justification, NAK.

-- 
With Best Regards,
Andy Shevchenko



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

  reply	other threads:[~2021-10-05 16:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 14:37 [PATCH v2 0/4] Add support for the Mercury+ AA1 module Paweł Anikiel
2021-10-05 14:37 ` Paweł Anikiel
2021-10-05 14:37 ` [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller Paweł Anikiel
2021-10-05 14:37   ` Paweł Anikiel
2021-10-05 16:19   ` Andy Shevchenko [this message]
2021-10-05 16:19     ` Andy Shevchenko
2021-10-05 14:37 ` [PATCH v2 2/4] dt-bindings: add bus number property Paweł Anikiel
2021-10-14 16:46   ` Rob Herring
2021-10-14 16:46     ` Rob Herring
2021-10-05 14:37 ` Paweł Anikiel
2021-10-05 14:37   ` Paweł Anikiel
2021-10-05 16:22   ` Arnd Bergmann
2021-10-05 16:22     ` Arnd Bergmann
2021-10-05 16:28     ` Alexandre Belloni
2021-10-05 16:28       ` Alexandre Belloni
2021-10-06  9:21       ` Paweł Anikiel
2021-10-06  9:41         ` Arnd Bergmann
2021-10-06  9:41           ` Arnd Bergmann
2021-10-06  9:29       ` Paweł Anikiel
2021-10-06  9:29         ` Paweł Anikiel
2021-10-05 14:37 ` [PATCH v2 3/4] reset: socfpga: add empty driver allowing consumers to probe Paweł Anikiel
2021-10-05 14:37   ` Paweł Anikiel
2021-10-05 14:37 ` [PATCH v2 4/4] dts: socfpga: Add Mercury+ AA1 devicetree Paweł Anikiel
2021-10-05 14:37   ` Paweł Anikiel

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=YVx7LdKo1f1KBpqr@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=amstan@google.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dinguyen@kernel.org \
    --cc=jam@semihalf.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=ka@semihalf.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=olof@lixom.net \
    --cc=p.yadav@ti.com \
    --cc=p.zabel@pengutronix.de \
    --cc=pan@semihalf.com \
    --cc=robh+dt@kernel.org \
    --cc=soc@kernel.org \
    --cc=sre@kernel.org \
    --cc=thunder.leizhen@huawei.com \
    --cc=tn@semihalf.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.