From: Andrew Lunn <andrew@lunn.ch>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Sekhar Nori <nsekhar@ti.com>, Kevin Hilman <khilman@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Grygorii Strashko <grygorii.strashko@ti.com>,
"David S . Miller" <davem@davemloft.net>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Lukas Wunner <lukas@wunner.de>, Rob Herring <robh@kernel.org>,
Florian Fainelli <f.fainelli@gmail.com>,
Dan Carpenter <dan.carpenter@oracle.com>,
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>,
David Lechner <david@lechnology.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-omap@vger.kernel.org, netdev@vger.kernel.org,
Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH 00/14] ARM: davinci: step towards removing at24_platform_data
Date: Tue, 26 Jun 2018 15:21:54 +0200 [thread overview]
Message-ID: <20180626132154.GA5064@lunn.ch> (raw)
In-Reply-To: <CAMRc=Mdvh+1enpD3qDoamhPfaBPin2v3amneQELApgoC0bS2FQ@mail.gmail.com>
> I see. I see it this way: the setup callback comes from the time when
> we didn't have nvmem and should go away. I will protest loud whenever
> someone will try to use it again and will work towards removing it as
> soon as possible.
The setup() callback could be moved into the nvmem framework, rather
than in the at24 driver. Make the call when the cells have been
connected to the backing store.
> I will give your problem a thought and will try to get back with some
> proposals - maybe we should, as you suggested, extend nvmem even
> further to allow to remove nvmem info entries etc.
That does not help me too much. I have the same problem with i2c and
MDIO. So i actually prefer to keep this the same as all others.
Andrew
next prev parent reply other threads:[~2018-06-26 13:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-25 15:50 [PATCH 00/14] ARM: davinci: step towards removing at24_platform_data Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 01/14] nvmem: add support for cell lookups Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 02/14] ARM: davinci: dm365-evm: use nvmem lookup for mac address Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 03/14] ARM: davinci: dm644-evm: " Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 04/14] ARM: davinci: dm646x-evm: " Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 05/14] ARM: davinci: da830-evm: " Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 06/14] ARM: davinci: mityomapl138: add nvmem cells lookup entries Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 07/14] net: davinci_emac: use nvmem to retrieve the mac address Bartosz Golaszewski
2018-06-25 23:09 ` Grygorii Strashko
2018-06-25 15:50 ` [PATCH 08/14] ARM: davinci: mityomapl138: don't read the MAC address from machine code Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 09/14] ARM: davinci: dm365-evm: use device properties for at24 eeprom Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 10/14] ARM: davinci: da830-evm: " Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 11/14] ARM: davinci: dm644x-evm: " Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 12/14] ARM: davinci: dm646x-evm: " Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 13/14] ARM: davinci: sffsdr: fix the at24 eeprom device name Bartosz Golaszewski
2018-06-25 15:50 ` [PATCH 14/14] ARM: davinci: sffsdr: use device properties for at24 eeprom Bartosz Golaszewski
2018-06-25 17:40 ` [PATCH 00/14] ARM: davinci: step towards removing at24_platform_data Andrew Lunn
2018-06-25 17:46 ` Bartosz Golaszewski
2018-06-25 18:02 ` Andrew Lunn
2018-06-26 7:44 ` Bartosz Golaszewski
2018-06-26 8:38 ` Andrew Lunn
2018-06-26 9:31 ` Bartosz Golaszewski
2018-06-26 13:21 ` Andrew Lunn [this message]
2018-06-26 13:38 ` Bartosz Golaszewski
2018-06-27 9:40 ` Bartosz Golaszewski
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=20180626132154.GA5064@lunn.ch \
--to=andrew@lunn.ch \
--cc=bgolaszewski@baylibre.com \
--cc=brgl@bgdev.pl \
--cc=dan.carpenter@oracle.com \
--cc=davem@davemloft.net \
--cc=david@lechnology.com \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=grygorii.strashko@ti.com \
--cc=ivan.khoronzhuk@linaro.org \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lukas@wunner.de \
--cc=netdev@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=robh@kernel.org \
--cc=srinivas.kandagatla@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).