* [PATCH bpf 1/3] bpf, sockmap: fix bpf_tcp_sendmsg sock error handling
From: Daniel Borkmann @ 2018-08-08 17:23 UTC (permalink / raw)
To: netdev; +Cc: ast, john.fastabend, Daniel Borkmann
In-Reply-To: <20180808172315.4710-1-daniel@iogearbox.net>
While working on bpf_tcp_sendmsg() code, I noticed that when a
sk->sk_err is set we error out with err = sk->sk_err. However
this is problematic since sk->sk_err is a positive error value
and therefore we will neither go into sk_stream_error() nor will
we report an error back to user space. I had this case with EPIPE
and user space was thinking sendmsg() succeeded since EPIPE is
a positive value, thinking we submitted 32 bytes. Fix it by
negating the sk->sk_err value.
Fixes: 4f738adba30a ("bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
---
kernel/bpf/sockmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 98fb793..f7360c4 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -1053,7 +1053,7 @@ static int bpf_tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
int copy;
if (sk->sk_err) {
- err = sk->sk_err;
+ err = -sk->sk_err;
goto out_err;
}
--
2.9.5
^ permalink raw reply related
* [PATCH bpf 2/3] bpf, sockmap: fix leak in bpf_tcp_sendmsg wait for mem path
From: Daniel Borkmann @ 2018-08-08 17:23 UTC (permalink / raw)
To: netdev; +Cc: ast, john.fastabend, Daniel Borkmann
In-Reply-To: <20180808172315.4710-1-daniel@iogearbox.net>
In bpf_tcp_sendmsg() the sk_alloc_sg() may fail. In the case of
ENOMEM, it may also mean that we've partially filled the scatterlist
entries with pages. Later jumping to sk_stream_wait_memory()
we could further fail with an error for several reasons, however
we miss to call free_start_sg() if the local sk_msg_buff was used.
Fixes: 4f738adba30a ("bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
---
kernel/bpf/sockmap.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index f7360c4..c4d75c5 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -1048,7 +1048,7 @@ static int bpf_tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
while (msg_data_left(msg)) {
- struct sk_msg_buff *m;
+ struct sk_msg_buff *m = NULL;
bool enospc = false;
int copy;
@@ -1116,8 +1116,11 @@ static int bpf_tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
wait_for_memory:
err = sk_stream_wait_memory(sk, &timeo);
- if (err)
+ if (err) {
+ if (m && m != psock->cork)
+ free_start_sg(sk, m);
goto out_err;
+ }
}
out_err:
if (err < 0)
--
2.9.5
^ permalink raw reply related
* [PATCH bpf 0/3] Couple of sockmap fixes
From: Daniel Borkmann @ 2018-08-08 17:23 UTC (permalink / raw)
To: netdev; +Cc: ast, john.fastabend, Daniel Borkmann
Two sockmap fixes in bpf_tcp_sendmsg(), and one fix for the
sockmap kernel selftest. Thanks!
Daniel Borkmann (3):
bpf, sockmap: fix bpf_tcp_sendmsg sock error handling
bpf, sockmap: fix leak in bpf_tcp_sendmsg wait for mem path
bpf, sockmap: fix cork timeout for select due to epipe
kernel/bpf/sockmap.c | 9 ++++++---
tools/testing/selftests/bpf/test_sockmap.c | 2 +-
2 files changed, 7 insertions(+), 4 deletions(-)
--
2.9.5
^ permalink raw reply
* Re: [PATCH net-next v1 1/1] net/tls: Combined memory allocation for decryption request
From: Dave Watson @ 2018-08-08 17:07 UTC (permalink / raw)
To: Vakul Garg; +Cc: netdev, borisp, aviadye, davem
In-Reply-To: <20180808130630.13568-2-vakul.garg@nxp.com>
On 08/08/18 06:36 PM, Vakul Garg wrote:
> For preparing decryption request, several memory chunks are required
> (aead_req, sgin, sgout, iv, aad). For submitting the decrypt request to
> an accelerator, it is required that the buffers which are read by the
> accelerator must be dma-able and not come from stack. The buffers for
> aad and iv can be separately kmalloced each, but it is inefficient.
> This patch does a combined allocation for preparing decryption request
> and then segments into aead_req || sgin || sgout || iv || aad.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> ---
> + n_sgout = sg_nents(out_sg);
> +
> + n_sgin = skb_nsg(skb, rxm->offset + tls_ctx->rx.prepend_size,
> + rxm->full_len - tls_ctx->rx.prepend_size);
> + } else {
> +no_zerocopy:
label is unused now
^ permalink raw reply
* Re: [PATCH net-next] netfilter: nfnetlink_osf: fix using plain integer as NULL warning
From: Pablo Neira Ayuso @ 2018-08-08 17:05 UTC (permalink / raw)
To: Wei Yongjun
Cc: Jozsef Kadlecsik, Florian Westphal, netfilter-devel, coreteam,
netdev, kernel-janitors
In-Reply-To: <1533698624-107304-1-git-send-email-weiyongjun1@huawei.com>
On Wed, Aug 08, 2018 at 03:23:44AM +0000, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> net/netfilter/nfnetlink_osf.c:274:24: warning:
> Using plain integer as NULL pointer
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v1 6/7] net: mvneta: Don't use GRO on Armada 3720
From: Andrew Lunn @ 2018-08-08 16:58 UTC (permalink / raw)
To: Marek Behún
Cc: linux-arm-kernel, netdev, Gregory CLEMENT, Tomas Hlavacek,
Russell King - ARM Linux
In-Reply-To: <20180808152706.21727-7-marek.behun@nic.cz>
On Wed, Aug 08, 2018 at 05:27:05PM +0200, Marek Behún wrote:
> For some reason on Armada 3720 boards (EspressoBin and Turris Mox) the
> networking driver behaves weirdly when using napi_gro_receive.
>
> For example downloading a big file from a local network (low ping) is
> fast, but when downloading from a remote server (higher ping), the
> download speed is at first high but drops rapidly to almost nothing or
> absolutely nothing.
>
> This is fixed when using netif_receive_skb instead of napi_gro_receive.
Before doing this, we should really understand what is going on. It is
probably just a driver bug which needs fixing. And GRO should be good
for performance, so we do want to use it, if possible.
Andrew
^ permalink raw reply
* Re: [PATCH 03/28] nvmem: add a notifier chain
From: Bartosz Golaszewski @ 2018-08-08 16:30 UTC (permalink / raw)
To: Andrew Lunn
Cc: Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori, Kevin Hilman,
Russell King, Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner
In-Reply-To: <20180808161353.GF7275@lunn.ch>
2018-08-08 18:13 GMT+02:00 Andrew Lunn <andrew@lunn.ch>:
> On Wed, Aug 08, 2018 at 05:31:25PM +0200, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> Add a blocking notifier chain with two events (add and remove) so that
>> users can get notified about the addition of nvmem devices they're
>> waiting for.
>>
>> We'll use this instead of the at24 setup callback in the mityomapl138
>> board file.
>
> Hi Bartosz
>
> What context is this notifier chain called in?
>
> I did something similar using the i2c notifier to try to work around
> the impending disappearing of the setup callback. But i got lockdep
> splats, because the notifier was called while some locks were being
> held, so it was not possible to register other i2c devices.
>
> The at24 setup callback is done as part of probe, so no important
> locks are held. Are any locks held when this notifier chain is called?
>
> Thanks
> Andrew
In the case of at24 it would be called from at24_probe() ->
nvmem_register() in process context. Would you mind testing it? Would
be great to see if it works on multiple setups.
Bart
^ permalink raw reply
* Re: [PATCH 00/33] net: ethernet: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-08-08 16:26 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-kernel, linux-net-drivers, ecree, bkenward, jes,
linux-acenic, michael.chan, nicolas.ferre, derek.chickles,
satananda.burla, felix.manlunas, raghu.vatsavayi, ganeshgr,
santosh, sgoutham, rric, linux-arm-kernel, linux-parisc,
sathya.perla, ajit.khaparde, sriharsha.basavapatna, somnath.kotur,
yisen.zhuang, salil.mehta, jeffrey.t.kirsher, intel-wired-lan,
tariqt, l
In-Reply-To: <20180807.175931.200772329178253653.davem@davemloft.net>
On 8/7/18 7:59 PM, David Miller wrote:
> From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
> Date: Tue, 7 Aug 2018 18:09:00 -0500
>
>> In preparation to enabling -Wimplicit-fallthrough, this patchset aims
>> to add some annotations in order to mark switch cases where we are
>> expecting to fall through.
>
> Ok, I went through all of these and they look good.
>
> If any are not correct we can revert/fix.
>
Yep. If anything is reported, I'll take a look right away.
> Series applied, thanks.
>
Thanks
^ permalink raw reply
* Re: [PATCH 00/28] at24: remove at24_platform_data
From: Bartosz Golaszewski @ 2018-08-08 16:27 UTC (permalink / raw)
To: Wolfram Sang
Cc: Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori, Kevin Hilman,
Russell King, Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse,
Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner
In-Reply-To: <20180808155548.s7p4xqsjywz3psrj@ninjato>
2018-08-08 17:55 GMT+02:00 Wolfram Sang <wsa@the-dreams.de>:
> On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> This is a follow-up to the previously rejected series[1] which partially
>> removed the at24_platform_data structure. After further development and
>> taking reviews into account, this series finally removes that struct
>> completely but not without touching many different parts of the code
>> base.
>>
>> Since I took over maintainership of the at24 driver I've been working
>> towards removing at24_platform_data in favor for device properties.
>
> Wooha, nice work. I can't really comment on it but wondered how you want
> to upstream it (after reviews)? Pull request of an immutable branch for
> nvmem-tree sounds best to me. Then I could also pull it in if i2c needs
> it. Probably same situation for arm-soc...
>
I initially wanted to merge small parts of it starting with v4.18, but
there were some voices against merging APIs without users. I'm not
sure how it should go in. There'll be a need for multiple immutable
branches most probably...
Bart
^ permalink raw reply
* Re: [PATCH iproute2] ip link: don't stop batch processing
From: Stephen Hemminger @ 2018-08-08 16:27 UTC (permalink / raw)
To: Matteo Croce; +Cc: netdev
In-Reply-To: <20180803174933.24600-1-mcroce@redhat.com>
On Fri, 3 Aug 2018 19:49:33 +0200
Matteo Croce <mcroce@redhat.com> wrote:
> When 'ip link show dev DEVICE' is processed in a batch mode, ip exits
> and stop processing further commands.
> This because ipaddr_list_flush_or_save() calls exit() to avoid printing
> the link information twice.
> Replace the exit with a classic goto out instruction.
>
> Signed-off-by: Matteo Croce <mcroce@redhat.com>
> ---
> ip/ipaddress.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index 6c306ab7..b7b78f6e 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -1920,7 +1920,7 @@ static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
> exit(1);
> }
> delete_json_obj();
> - exit(0);
> + goto out;
> }
>
> if (filter.family != AF_PACKET) {
Applied
^ permalink raw reply
* Re: [PATCH iproute2] ip link: don't stop batch processing
From: Stephen Hemminger @ 2018-08-08 16:26 UTC (permalink / raw)
To: Dave Taht; +Cc: mcroce, Linux Kernel Network Developers
In-Reply-To: <CAA93jw7+A2Fp+vsra1=cT+cP6BnvpNiiCJqhtqZZBkRzVdZB6w@mail.gmail.com>
On Fri, 3 Aug 2018 11:08:58 -0700
Dave Taht <dave.taht@gmail.com> wrote:
> On Fri, Aug 3, 2018 at 10:50 AM Matteo Croce <mcroce@redhat.com> wrote:
> >
> > When 'ip link show dev DEVICE' is processed in a batch mode, ip exits
> > and stop processing further commands.
> > This because ipaddr_list_flush_or_save() calls exit() to avoid printing
> > the link information twice.
> > Replace the exit with a classic goto out instruction.
> >
> > Signed-off-by: Matteo Croce <mcroce@redhat.com>
>
> one thing I noticed in iproute2-next last week is that
>
> ( echo qdisc show dev eno1; sleep 5; echo qdisc show dev eno1; ) | tc -b -
>
> batches the whole thing up to emerge on exit, only.
>
> It didn't used to do that, the output of every command came out as it
> completed. I used to use that to timestamp and save the overhead of
> invoking the tc utility on openwrt while monitoring qdisc stats in
> https://github.com/tohojo/flent/blob/master/misc/tc_iterate.c
There used to be lots of fflush(stdout) in each sub command but lots of these
got dropped in JSON updates.
I just added one back in after each batch command that should fix what you are seeing.
^ permalink raw reply
* RE: [PATCH lora-next 01/10] net: lora: sx1301: add register, bit-fields, and helpers for regmap
From: Ben Whitten @ 2018-08-08 15:52 UTC (permalink / raw)
To: Andreas Färber, Ben Whitten
Cc: starnight@g.ncu.edu.tw, hasnain.virk@arm.com,
netdev@vger.kernel.org
In-Reply-To: <f0b0a89d-6e32-10e6-4270-0f504d19bc6c@suse.de>
> Subject: Re: [PATCH lora-next 01/10] net: lora: sx1301: add
> register, bit-fields, and helpers for regmap
>
> Am 08.08.2018 um 14:32 schrieb Ben Whitten:
> >>> drivers/net/lora/Kconfig | 1 +
> >>> drivers/net/lora/sx1301.c | 282
> >> +++++++++++++++++++++++++++++++++++++++++++-
> --
> >>> drivers/net/lora/sx1301.h | 169
> >> +++++++++++++++++++++++++++
> >>> 3 files changed, 439 insertions(+), 13 deletions(-)
> >>> create mode 100644 drivers/net/lora/sx1301.h
> >>
> >> My main concern about this patch is its sheer size.
> Normally
> >> for
> >> #defines the rule is not to add unused ones. Here I see
> for
> >> example FSK
> >> RSSI fields that we're surely not using yet. Any chance to
> >> strip this
> >> down some more?
> >
> > Sure, I'll strip the reg_fields down to those only required
> for
> > loading firmware and setting clocks that will be used in the
> > immediate term. This does clutter the driver a bit
> > unnecessarily at the moment.
> > I would like to keep the full register dump in the header
> file
> > though as its self-contained and gives a full picture of the
> chip.
>
> Could you do that in more steps though? I'm thinking,
> convert only the
> registers in use to regmap (that'll make it easier to review),
> then add
> more registers, then convert to regmap fields?
I split the conversion function by function but we can probably go
further if you think it helpful.
Is it more the addition of the replacement register defines that you
would like to correlate with what's being removed, so you can see
in one patch that this register has the same page and the same
address in the new system?
The problem I face is that these conversions are almost blind as
when I run on my hardware I either oops with the sx1301_read
or the cal firmware doesn't verify so I can't finish probe. I only
get a full sx1301 module probe pass on physical hardware when
I get right to the end of the series where it's all replaced with
regmap.
Regards,
Ben Whitten
^ permalink raw reply
* Re: [PATCH] 9p: fix NULL pointer dereferences
From: Dmitry Vyukov @ 2018-08-08 15:51 UTC (permalink / raw)
To: Dominique Martinet
Cc: Tomas Bortoli, David Miller, v9fs-developer, netdev, LKML,
syzkaller
In-Reply-To: <20180726221527.GA9426@nautica>
On Fri, Jul 27, 2018 at 12:15 AM, Dominique Martinet
<asmadeus@codewreck.org> wrote:
> Tomas Bortoli wrote on Thu, Jul 26, 2018:
>> > If we want to preserve the current behaviour for trans=fd (and I don't
>> > see why not) we just have to patch all the transports that use the
>> > device, that is all .create functions but p9_fd_create()
>> >
>> > Basically exactly what you did, just for a few more functions - I
>> > apparently was a little bit too optimistic thinking we could share
>> > this check.
>>
>> Does v9fs_mount() knows the transport ahead? Because in that case it'd
>> be possible to check if addr!=NULL && trans!=fd then return error
>>
>> Otherwise, patching all the .create, ok.
>
> 9p option parsing is all over the place, split in fs/9p/v9fs,
> net/9p/client and net/9p/trans_*... Which is actually somewhat of a
> problem because that means we can't warn on unused option as each parser
> does not know the full subset of options used, so if someone makes a
> typo they're on their own to figure it out :/
>
>
> If you want to factor it in, v9fs_mount does not know which transport is
> used, but p9_client_create does know - although the functions/structs
> are all static so you need to check clnt->trans_mod->name with strcmp
> and I'm honestly not sure that's better than checking in each function..
>
> But, as usual I'm happy as long as it works, so pick your poison :)
So let's proceed with checking in each transport function?
^ permalink raw reply
* Re: [PATCH][can-next] can: ucan: fix spelling mistake: "resumbmitting" -> "resubmitting"
From: Marc Kleine-Budde @ 2018-08-08 15:47 UTC (permalink / raw)
To: Colin King, Wolfgang Grandegger, David S . Miller, linux-can,
netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180730134037.8240-1-colin.king@canonical.com>
[-- Attachment #1.1: Type: text/plain, Size: 538 bytes --]
On 07/30/2018 03:40 PM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in netdev_dbg error message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to can-next.
Tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] ethernet/qlogic: remove unused array msi_tgt_status
From: Colin King @ 2018-08-08 18:04 UTC (permalink / raw)
To: Harish Patil, Manish Chopra, Dept-GELinuxNICDev, David S . Miller,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Array msi_tgt_status is defined but never used, hence it is
redundant and can be removed.
Cleans up clang warning:
warning: 'msi_tgt_status' defined but not used [-Wunused-const-variable=]
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
index 7848cf04b29a..822aa393c370 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
@@ -276,13 +276,6 @@ static const unsigned crb_hub_agt[64] = {
0,
};
-static const u32 msi_tgt_status[8] = {
- ISR_INT_TARGET_STATUS, ISR_INT_TARGET_STATUS_F1,
- ISR_INT_TARGET_STATUS_F2, ISR_INT_TARGET_STATUS_F3,
- ISR_INT_TARGET_STATUS_F4, ISR_INT_TARGET_STATUS_F5,
- ISR_INT_TARGET_STATUS_F6, ISR_INT_TARGET_STATUS_F7
-};
-
/* PCI Windowing for DDR regions. */
#define QLCNIC_PCIE_SEM_TIMEOUT 10000
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 27/28] ARM: davinci: mityomapl138: use device properties for at24 eeprom
From: Andy Shevchenko @ 2018-08-08 18:00 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <CAHp75VdBkSHtqXkzRJgOHwaL5UhgV+TgySjEs57bisbKTpO4SQ@mail.gmail.com>
On Wed, Aug 8, 2018 at 8:58 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> We want to work towards phasing out the at24_platform_data structure.
>> There are few users and its contents can be represented using generic
>> device properties. Using device properties only will allow us to
>> significantly simplify the at24 configuration code.
>>
>> Remove the at24_platform_data structure and replace it with an array
>> of property entries. Drop the byte_len/size property, as the model name
>> already implies the EEPROM's size.
>>
>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> arch/arm/mach-davinci/board-mityomapl138.c | 11 +++++------
>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
>> index 17b67e26bc0e..be0fb7d17e25 100644
>> --- a/arch/arm/mach-davinci/board-mityomapl138.c
>> +++ b/arch/arm/mach-davinci/board-mityomapl138.c
>> @@ -14,11 +14,11 @@
>> #include <linux/init.h>
>> #include <linux/console.h>
>> #include <linux/platform_device.h>
>> +#include <linux/property.h>
>> #include <linux/mtd/partitions.h>
>> #include <linux/notifier.h>
>> #include <linux/regulator/machine.h>
>> #include <linux/i2c.h>
>> -#include <linux/platform_data/at24.h>
>> #include <linux/etherdevice.h>
>> #include <linux/spi/spi.h>
>> #include <linux/spi/flash.h>
>> @@ -185,10 +185,9 @@ static struct nvmem_cell_lookup mityomapl138_nvmem_cells[] = {
>> }
>> };
>>
>> -static struct at24_platform_data mityomapl138_fd_chip = {
>> - .byte_len = 256,
>> - .page_size = 8,
>> - .flags = AT24_FLAG_READONLY | AT24_FLAG_IRUGO,
>> +static const struct property_entry mityomapl138_fd_chip_properties[] = {
>> + PROPERTY_ENTRY_U32("pagesize", 8),
>> + PROPERTY_ENTRY_BOOL("read-only"),
Missed terminator
>> };
>>
>> static struct davinci_i2c_platform_data mityomap_i2c_0_pdata = {
>> @@ -317,7 +316,7 @@ static struct i2c_board_info __initdata mityomap_tps65023_info[] = {
>> },
>> {
>> I2C_BOARD_INFO("24c02", 0x50),
>> - .platform_data = &mityomapl138_fd_chip,
>> + .properties = mityomapl138_fd_chip_properties,
>> },
>> };
>>
>> --
>> 2.18.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 24/28] ARM: davinci: sffsdr: use device properties for at24 eeprom
From: Andy Shevchenko @ 2018-08-08 18:00 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <CAHp75VfU6Dsge0XX5h18zjY9kJ73kFPevLT9j7vZBO__tNronw@mail.gmail.com>
On Wed, Aug 8, 2018 at 8:57 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> We want to work towards phasing out the at24_platform_data structure.
>> There are few users and its contents can be represented using generic
>> device properties. Using device properties only will allow us to
>> significantly simplify the at24 configuration code.
>>
>> Remove the at24_platform_data structure and replace it with an array
>> of property entries. Drop the byte_len/size property, as the model name
>> already implies the EEPROM's size.
>>
>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> arch/arm/mach-davinci/board-sffsdr.c | 11 +++++------
>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
>> index f6a4d094cbc3..680e5d7628a8 100644
>> --- a/arch/arm/mach-davinci/board-sffsdr.c
>> +++ b/arch/arm/mach-davinci/board-sffsdr.c
>> @@ -26,7 +26,7 @@
>> #include <linux/init.h>
>> #include <linux/platform_device.h>
>> #include <linux/i2c.h>
>> -#include <linux/platform_data/at24.h>
>> +#include <linux/property.h>
>> #include <linux/mtd/mtd.h>
>> #include <linux/mtd/rawnand.h>
>> #include <linux/mtd/partitions.h>
>> @@ -92,16 +92,15 @@ static struct platform_device davinci_sffsdr_nandflash_device = {
>> .resource = davinci_sffsdr_nandflash_resource,
>> };
>>
>> -static struct at24_platform_data eeprom_info = {
>> - .byte_len = (64*1024) / 8,
>> - .page_size = 32,
>> - .flags = AT24_FLAG_ADDR16,
>> +static const struct property_entry eeprom_properties[] = {
>> + PROPERTY_ENTRY_U32("pagesize", 32),
>> + { },
No comma needed
>> };
>>
>> static struct i2c_board_info __initdata i2c_info[] = {
>> {
>> I2C_BOARD_INFO("24c64", 0x50),
>> - .platform_data = &eeprom_info,
>> + .properties = eeprom_properties,
>> },
>> /* Other I2C devices:
>> * MSP430, addr 0x23 (not used)
>> --
>> 2.18.0
>>
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 21/28] ARM: davinci: dm644x-evm: use device properties for at24 eeprom
From: Andy Shevchenko @ 2018-08-08 17:59 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <CAHp75VewdvD2D2BpyKAptFecr+hrW5O5YUcSzu9X4wGgV-oJ3A@mail.gmail.com>
On Wed, Aug 8, 2018 at 8:55 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> We want to work towards phasing out the at24_platform_data structure.
>> There are few users and its contents can be represented using generic
>> device properties. Using device properties only will allow us to
>> significantly simplify the at24 configuration code.
>>
>> Remove the at24_platform_data structure and replace it with an array
>> of property entries. Drop the byte_len/size property, as the model name
>> already implies the EEPROM's size.
>>
>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> arch/arm/mach-davinci/board-dm644x-evm.c | 12 ++++--------
>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
>> index 6d35c6e1b0bd..abfcf42da6fb 100644
>> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
>> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
>> @@ -16,8 +16,8 @@
>> #include <linux/gpio/machine.h>
>> #include <linux/i2c.h>
>> #include <linux/platform_data/pcf857x.h>
>> -#include <linux/platform_data/at24.h>
>> #include <linux/platform_data/gpio-davinci.h>
>> +#include <linux/property.h>
>> #include <linux/mtd/mtd.h>
>> #include <linux/mtd/rawnand.h>
>> #include <linux/mtd/partitions.h>
>> @@ -486,12 +486,8 @@ static struct nvmem_cell_lookup dm6446evm_mac_address_cell = {
>> .nvmem_name = "1-00500",
>> };
>>
>> -static struct at24_platform_data eeprom_info = {
>> - .byte_len = (256*1024) / 8,
>> - .page_size = 64,
>> - .flags = AT24_FLAG_ADDR16,
>> - .setup = davinci_get_mac_addr,
>> - .context = (void *)0x7f00,
>> +static const struct property_entry eeprom_properties[] = {
>> + PROPERTY_ENTRY_U32("pagesize", 64),
Missed terminator, though
>> };
>>
>> /*
>> @@ -601,7 +597,7 @@ static struct i2c_board_info __initdata i2c_info[] = {
>> },
>> {
>> I2C_BOARD_INFO("24c256", 0x50),
>> - .platform_data = &eeprom_info,
>> + .properties = eeprom_properties,
>> },
>> {
>> I2C_BOARD_INFO("tlv320aic33", 0x1b),
>> --
>> 2.18.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 27/28] ARM: davinci: mityomapl138: use device properties for at24 eeprom
From: Andy Shevchenko @ 2018-08-08 17:58 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180808153150.23444-28-brgl@bgdev.pl>
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> We want to work towards phasing out the at24_platform_data structure.
> There are few users and its contents can be represented using generic
> device properties. Using device properties only will allow us to
> significantly simplify the at24 configuration code.
>
> Remove the at24_platform_data structure and replace it with an array
> of property entries. Drop the byte_len/size property, as the model name
> already implies the EEPROM's size.
>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/mach-davinci/board-mityomapl138.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
> index 17b67e26bc0e..be0fb7d17e25 100644
> --- a/arch/arm/mach-davinci/board-mityomapl138.c
> +++ b/arch/arm/mach-davinci/board-mityomapl138.c
> @@ -14,11 +14,11 @@
> #include <linux/init.h>
> #include <linux/console.h>
> #include <linux/platform_device.h>
> +#include <linux/property.h>
> #include <linux/mtd/partitions.h>
> #include <linux/notifier.h>
> #include <linux/regulator/machine.h>
> #include <linux/i2c.h>
> -#include <linux/platform_data/at24.h>
> #include <linux/etherdevice.h>
> #include <linux/spi/spi.h>
> #include <linux/spi/flash.h>
> @@ -185,10 +185,9 @@ static struct nvmem_cell_lookup mityomapl138_nvmem_cells[] = {
> }
> };
>
> -static struct at24_platform_data mityomapl138_fd_chip = {
> - .byte_len = 256,
> - .page_size = 8,
> - .flags = AT24_FLAG_READONLY | AT24_FLAG_IRUGO,
> +static const struct property_entry mityomapl138_fd_chip_properties[] = {
> + PROPERTY_ENTRY_U32("pagesize", 8),
> + PROPERTY_ENTRY_BOOL("read-only"),
> };
>
> static struct davinci_i2c_platform_data mityomap_i2c_0_pdata = {
> @@ -317,7 +316,7 @@ static struct i2c_board_info __initdata mityomap_tps65023_info[] = {
> },
> {
> I2C_BOARD_INFO("24c02", 0x50),
> - .platform_data = &mityomapl138_fd_chip,
> + .properties = mityomapl138_fd_chip_properties,
> },
> };
>
> --
> 2.18.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 24/28] ARM: davinci: sffsdr: use device properties for at24 eeprom
From: Andy Shevchenko @ 2018-08-08 17:57 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180808153150.23444-25-brgl@bgdev.pl>
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> We want to work towards phasing out the at24_platform_data structure.
> There are few users and its contents can be represented using generic
> device properties. Using device properties only will allow us to
> significantly simplify the at24 configuration code.
>
> Remove the at24_platform_data structure and replace it with an array
> of property entries. Drop the byte_len/size property, as the model name
> already implies the EEPROM's size.
>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/mach-davinci/board-sffsdr.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
> index f6a4d094cbc3..680e5d7628a8 100644
> --- a/arch/arm/mach-davinci/board-sffsdr.c
> +++ b/arch/arm/mach-davinci/board-sffsdr.c
> @@ -26,7 +26,7 @@
> #include <linux/init.h>
> #include <linux/platform_device.h>
> #include <linux/i2c.h>
> -#include <linux/platform_data/at24.h>
> +#include <linux/property.h>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/rawnand.h>
> #include <linux/mtd/partitions.h>
> @@ -92,16 +92,15 @@ static struct platform_device davinci_sffsdr_nandflash_device = {
> .resource = davinci_sffsdr_nandflash_resource,
> };
>
> -static struct at24_platform_data eeprom_info = {
> - .byte_len = (64*1024) / 8,
> - .page_size = 32,
> - .flags = AT24_FLAG_ADDR16,
> +static const struct property_entry eeprom_properties[] = {
> + PROPERTY_ENTRY_U32("pagesize", 32),
> + { },
> };
>
> static struct i2c_board_info __initdata i2c_info[] = {
> {
> I2C_BOARD_INFO("24c64", 0x50),
> - .platform_data = &eeprom_info,
> + .properties = eeprom_properties,
> },
> /* Other I2C devices:
> * MSP430, addr 0x23 (not used)
> --
> 2.18.0
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 22/28] ARM: davinci: dm646x-evm: use device properties for at24 eeprom
From: Andy Shevchenko @ 2018-08-08 17:56 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180808153150.23444-23-brgl@bgdev.pl>
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> We want to work towards phasing out the at24_platform_data structure.
> There are few users and its contents can be represented using generic
> device properties. Using device properties only will allow us to
> significantly simplify the at24 configuration code.
>
> Remove the at24_platform_data structure and replace it with an array
> of property entries. Drop the byte_len/size property, as the model name
> already implies the EEPROM's size.
>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/mach-davinci/board-dm646x-evm.c | 13 +++++--------
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
> index 5a9de47bc8a2..5049f0c6cd1a 100644
> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
> @@ -22,7 +22,7 @@
> #include <linux/gpio.h>
> #include <linux/platform_device.h>
> #include <linux/i2c.h>
> -#include <linux/platform_data/at24.h>
> +#include <linux/property.h>
> #include <linux/platform_data/pcf857x.h>
>
> #include <media/i2c/tvp514x.h>
> @@ -320,12 +320,9 @@ static struct nvmem_cell_lookup dm646x_evm_mac_address_cell = {
> .nvmem_name = "1-00500",
> };
>
> -static struct at24_platform_data eeprom_info = {
> - .byte_len = (256*1024) / 8,
> - .page_size = 64,
> - .flags = AT24_FLAG_ADDR16,
> - .setup = davinci_get_mac_addr,
> - .context = (void *)0x7f00,
> +static const struct property_entry eeprom_properties[] = {
> + PROPERTY_ENTRY_U32("pagesize", 64),
> + { }
> };
> #endif
>
> @@ -396,7 +393,7 @@ static void evm_init_cpld(void)
> static struct i2c_board_info __initdata i2c_info[] = {
> {
> I2C_BOARD_INFO("24c256", 0x50),
> - .platform_data = &eeprom_info,
> + .properties = eeprom_properties,
> },
> {
> I2C_BOARD_INFO("pcf8574a", 0x38),
> --
> 2.18.0
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 21/28] ARM: davinci: dm644x-evm: use device properties for at24 eeprom
From: Andy Shevchenko @ 2018-08-08 17:55 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180808153150.23444-22-brgl@bgdev.pl>
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> We want to work towards phasing out the at24_platform_data structure.
> There are few users and its contents can be represented using generic
> device properties. Using device properties only will allow us to
> significantly simplify the at24 configuration code.
>
> Remove the at24_platform_data structure and replace it with an array
> of property entries. Drop the byte_len/size property, as the model name
> already implies the EEPROM's size.
>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/mach-davinci/board-dm644x-evm.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
> index 6d35c6e1b0bd..abfcf42da6fb 100644
> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
> @@ -16,8 +16,8 @@
> #include <linux/gpio/machine.h>
> #include <linux/i2c.h>
> #include <linux/platform_data/pcf857x.h>
> -#include <linux/platform_data/at24.h>
> #include <linux/platform_data/gpio-davinci.h>
> +#include <linux/property.h>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/rawnand.h>
> #include <linux/mtd/partitions.h>
> @@ -486,12 +486,8 @@ static struct nvmem_cell_lookup dm6446evm_mac_address_cell = {
> .nvmem_name = "1-00500",
> };
>
> -static struct at24_platform_data eeprom_info = {
> - .byte_len = (256*1024) / 8,
> - .page_size = 64,
> - .flags = AT24_FLAG_ADDR16,
> - .setup = davinci_get_mac_addr,
> - .context = (void *)0x7f00,
> +static const struct property_entry eeprom_properties[] = {
> + PROPERTY_ENTRY_U32("pagesize", 64),
> };
>
> /*
> @@ -601,7 +597,7 @@ static struct i2c_board_info __initdata i2c_info[] = {
> },
> {
> I2C_BOARD_INFO("24c256", 0x50),
> - .platform_data = &eeprom_info,
> + .properties = eeprom_properties,
> },
> {
> I2C_BOARD_INFO("tlv320aic33", 0x1b),
> --
> 2.18.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 20/28] ARM: davinci: da830-evm: use device properties for at24 eeprom
From: Andy Shevchenko @ 2018-08-08 17:55 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
In-Reply-To: <20180808153150.23444-21-brgl@bgdev.pl>
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> We want to work towards phasing out the at24_platform_data structure.
> There are few users and its contents can be represented using generic
> device properties. Using device properties only will allow us to
> significantly simplify the at24 configuration code.
>
> Remove the at24_platform_data structure and replace it with an array
> of property entries. Drop the byte_len/size property, as the model name
> already implies the EEPROM's size.
>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/mach-davinci/board-da830-evm.c | 13 +++++--------
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
> index 4a2fe8142a2f..08a23e777eca 100644
> --- a/arch/arm/mach-davinci/board-da830-evm.c
> +++ b/arch/arm/mach-davinci/board-da830-evm.c
> @@ -18,7 +18,7 @@
> #include <linux/platform_device.h>
> #include <linux/i2c.h>
> #include <linux/platform_data/pcf857x.h>
> -#include <linux/platform_data/at24.h>
> +#include <linux/property.h>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/partitions.h>
> #include <linux/spi/spi.h>
> @@ -419,12 +419,9 @@ static struct nvmem_cell_lookup da830_evm_mac_address_cell = {
> .nvmem_name = "1-00500",
> };
>
> -static struct at24_platform_data da830_evm_i2c_eeprom_info = {
> - .byte_len = SZ_256K / 8,
> - .page_size = 64,
> - .flags = AT24_FLAG_ADDR16,
> - .setup = davinci_get_mac_addr,
> - .context = (void *)0x7f00,
> +static const struct property_entry da830_evm_i2c_eeprom_properties[] = {
> + PROPERTY_ENTRY_U32("pagesize", 64),
> + { }
> };
>
> static int __init da830_evm_ui_expander_setup(struct i2c_client *client,
> @@ -458,7 +455,7 @@ static struct pcf857x_platform_data __initdata da830_evm_ui_expander_info = {
> static struct i2c_board_info __initdata da830_evm_i2c_devices[] = {
> {
> I2C_BOARD_INFO("24c256", 0x50),
> - .platform_data = &da830_evm_i2c_eeprom_info,
> + .properties = da830_evm_i2c_eeprom_properties,
> },
> {
> I2C_BOARD_INFO("tlv320aic3x", 0x18),
> --
> 2.18.0
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 27/28] ARM: davinci: mityomapl138: use device properties for at24 eeprom
From: Bartosz Golaszewski @ 2018-08-08 15:31 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180808153150.23444-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We want to work towards phasing out the at24_platform_data structure.
There are few users and its contents can be represented using generic
device properties. Using device properties only will allow us to
significantly simplify the at24 configuration code.
Remove the at24_platform_data structure and replace it with an array
of property entries. Drop the byte_len/size property, as the model name
already implies the EEPROM's size.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-mityomapl138.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 17b67e26bc0e..be0fb7d17e25 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -14,11 +14,11 @@
#include <linux/init.h>
#include <linux/console.h>
#include <linux/platform_device.h>
+#include <linux/property.h>
#include <linux/mtd/partitions.h>
#include <linux/notifier.h>
#include <linux/regulator/machine.h>
#include <linux/i2c.h>
-#include <linux/platform_data/at24.h>
#include <linux/etherdevice.h>
#include <linux/spi/spi.h>
#include <linux/spi/flash.h>
@@ -185,10 +185,9 @@ static struct nvmem_cell_lookup mityomapl138_nvmem_cells[] = {
}
};
-static struct at24_platform_data mityomapl138_fd_chip = {
- .byte_len = 256,
- .page_size = 8,
- .flags = AT24_FLAG_READONLY | AT24_FLAG_IRUGO,
+static const struct property_entry mityomapl138_fd_chip_properties[] = {
+ PROPERTY_ENTRY_U32("pagesize", 8),
+ PROPERTY_ENTRY_BOOL("read-only"),
};
static struct davinci_i2c_platform_data mityomap_i2c_0_pdata = {
@@ -317,7 +316,7 @@ static struct i2c_board_info __initdata mityomap_tps65023_info[] = {
},
{
I2C_BOARD_INFO("24c02", 0x50),
- .platform_data = &mityomapl138_fd_chip,
+ .properties = mityomapl138_fd_chip_properties,
},
};
--
2.18.0
^ permalink raw reply related
* [PATCH 26/28] ARM: davinci: mityomapl138: use nvmem notifiers
From: Bartosz Golaszewski @ 2018-08-08 15:31 UTC (permalink / raw)
To: Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Boris Brezillon, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Srinivas Kandagatla, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter
Cc: linux-doc, linux-kernel, linux-arm-kernel, linux-i2c, linux-mtd,
linux-omap, netdev, Bartosz Golaszewski
In-Reply-To: <20180808153150.23444-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Stop using the at24_platform_data setup callback in favor of nvmem
notifiers.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-mityomapl138.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index 5c0a0557a361..17b67e26bc0e 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -15,12 +15,14 @@
#include <linux/console.h>
#include <linux/platform_device.h>
#include <linux/mtd/partitions.h>
+#include <linux/notifier.h>
#include <linux/regulator/machine.h>
#include <linux/i2c.h>
#include <linux/platform_data/at24.h>
#include <linux/etherdevice.h>
#include <linux/spi/spi.h>
#include <linux/spi/flash.h>
+#include <linux/nvmem-consumer.h>
#include <linux/nvmem-provider.h>
#include <asm/io.h>
@@ -116,10 +118,15 @@ static void mityomapl138_cpufreq_init(const char *partnum)
static void mityomapl138_cpufreq_init(const char *partnum) { }
#endif
-static void read_factory_config(struct nvmem_device *nvmem, void *context)
+static int read_factory_config(struct notifier_block *nb,
+ unsigned long event, void *data)
{
int ret;
const char *partnum = NULL;
+ struct nvmem_device *nvmem = data;
+
+ if (strcmp(nvmem_device_name(nvmem), "1-00500") != 0)
+ return NOTIFY_DONE;
if (!IS_BUILTIN(CONFIG_NVMEM)) {
pr_warn("Factory Config not available without CONFIG_NVMEM\n");
@@ -151,8 +158,14 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)
bad_config:
/* default maximum speed is valid for all platforms */
mityomapl138_cpufreq_init(partnum);
+
+ return NOTIFY_STOP;
}
+static struct notifier_block mityomapl138_nvmem_notifier = {
+ .notifier_call = read_factory_config,
+};
+
static struct nvmem_cell_lookup mityomapl138_nvmem_cells[] = {
{
.info = {
@@ -176,8 +189,6 @@ static struct at24_platform_data mityomapl138_fd_chip = {
.byte_len = 256,
.page_size = 8,
.flags = AT24_FLAG_READONLY | AT24_FLAG_IRUGO,
- .setup = read_factory_config,
- .context = NULL,
};
static struct davinci_i2c_platform_data mityomap_i2c_0_pdata = {
@@ -546,6 +557,7 @@ static void __init mityomapl138_init(void)
if (ret)
pr_warn("spi 1 registration failed: %d\n", ret);
+ nvmem_register_notifier(&mityomapl138_nvmem_notifier);
nvmem_add_lookup_table(mityomapl138_nvmem_cells,
ARRAY_SIZE(mityomapl138_nvmem_cells));
mityomapl138_config_emac();
--
2.18.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox