* Re: [PATCH 04/28] nvmem: provide nvmem_device_name()
From: Andy Shevchenko @ 2018-08-08 17:42 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-5-brgl@bgdev.pl>
On Wed, Aug 8, 2018 at 6:31 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Kernel users don't have any means of checking the names of nvmem
> devices. Add a routine that returns the name of the nvmem provider.
>
> This will be useful for nvmem notifier subscribers - otherwise they
> can't check what device is being added/removed.
> +const char *nvmem_device_name(struct nvmem_device *nvmem)
> +{
> + return dev_name(&nvmem->dev);
> +}
> +EXPORT_SYMBOL_GPL(nvmem_device_name);
Just wondering if *_dev_name() is more common pattern in the kernel
(at least pci_dev_name() comes immediately to mind).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 07/28] ARM: davinci: dm365-evm: use nvmem lookup for mac address
From: Andy Shevchenko @ 2018-08-08 17:43 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-8-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 now support nvmem lookups for machine code. Add a lookup for
> mac-address.
> #include <linux/spi/spi.h>
> #include <linux/spi/eeprom.h>
> #include <linux/v4l2-dv-timings.h>
> +#include <linux/nvmem-provider.h>
It looks from this context that your patch broke the order.
P.S. Can you verify all in the series for this?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v1 6/7] net: mvneta: Don't use GRO on Armada 3720
From: Marek Behún @ 2018-08-08 15:27 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Gregory CLEMENT, Tomas Hlavacek, Marek Behún,
Russell King - ARM Linux, netdev
In-Reply-To: <20180808152706.21727-1-marek.behun@nic.cz>
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.
Signed-off-by: Marek Behun <marek.behun@nic.cz>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: netdev@vger.kernel.org
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 0ad2f3f7da85..27f3017d94c5 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1959,7 +1959,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
skb->protocol = eth_type_trans(skb, dev);
mvneta_rx_csum(pp, rx_status, skb);
- napi_gro_receive(&port->napi, skb);
+ if (pp->neta_armada3700)
+ netif_receive_skb(skb);
+ else
+ napi_gro_receive(&port->napi, skb);
rcvd_pkts++;
rcvd_bytes += rx_bytes;
@@ -2001,7 +2004,10 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
mvneta_rx_csum(pp, rx_status, skb);
- napi_gro_receive(&port->napi, skb);
+ if (pp->neta_armada3700)
+ netif_receive_skb(skb);
+ else
+ napi_gro_receive(&port->napi, skb);
}
if (rcvd_pkts) {
--
2.16.4
^ permalink raw reply related
* Re: [PATCH 14/28] net: split eth_platform_get_mac_address() into subroutines
From: Andy Shevchenko @ 2018-08-08 17:50 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-15-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 do add more sources from which to read the MAC address. In
> order to avoid bloating this function too much, start by splitting it
> into subroutines, each of which takes care of reading the MAC from
> one source.
> +static int mac_address_from_of(struct device *dev, u8 *mac_addr)
> {
> const unsigned char *addr;
> + struct device_node *np;
>
> + np = dev_is_pci(dev) ? pci_device_to_OF_node(to_pci_dev(dev))
> + : dev->of_node;
I didn't get these manipulations.
What the scenario when pci_dev->dev.of_node != dev->of_node?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 10/28] ARM: davinci: da830-evm: use nvmem lookup for mac address
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 now support nvmem lookups for machine code. Add a lookup for
mac-address.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 14a6fc061744..4a2fe8142a2f 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -29,6 +29,7 @@
#include <linux/platform_data/spi-davinci.h>
#include <linux/platform_data/usb-davinci.h>
#include <linux/regulator/machine.h>
+#include <linux/nvmem-provider.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -409,6 +410,15 @@ static inline void da830_evm_init_lcdc(int mux_mode)
static inline void da830_evm_init_lcdc(int mux_mode) { }
#endif
+static struct nvmem_cell_lookup da830_evm_mac_address_cell = {
+ .info = {
+ .name = "mac-address",
+ .offset = 0x7f00,
+ .bytes = ETH_ALEN,
+ },
+ .nvmem_name = "1-00500",
+};
+
static struct at24_platform_data da830_evm_i2c_eeprom_info = {
.byte_len = SZ_256K / 8,
.page_size = 64,
@@ -618,6 +628,8 @@ static __init void da830_evm_init(void)
pr_warn("%s: spi 0 registration failed: %d\n", __func__, ret);
regulator_has_full_constraints();
+
+ nvmem_add_lookup_table(&da830_evm_mac_address_cell, 1);
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
--
2.18.0
^ permalink raw reply related
* Re: [PATCH 19/28] ARM: davinci: dm365-evm: use device properties for at24 eeprom
From: Andy Shevchenko @ 2018-08-08 17:54 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-20-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.
>
Yes, that exactly how device properties should be used instead of
legacy platform data!
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/mach-davinci/board-dm365-evm.c | 13 +++++--------
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
> index cb0ac92a278e..b360d26e6caa 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -18,7 +18,7 @@
> #include <linux/i2c.h>
> #include <linux/io.h>
> #include <linux/clk.h>
> -#include <linux/platform_data/at24.h>
> +#include <linux/property.h>
> #include <linux/leds.h>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/partitions.h>
> @@ -179,18 +179,15 @@ static struct nvmem_cell_lookup dm365evm_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),
> + { }
> };
>
> static struct i2c_board_info i2c_info[] = {
> {
> I2C_BOARD_INFO("24c256", 0x50),
> - .platform_data = &eeprom_info,
> + .properties = eeprom_properties,
> },
> {
> I2C_BOARD_INFO("tlv320aic3x", 0x18),
> --
> 2.18.0
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 18/28] ARM: davinci: mityomapl138: don't read the MAC address from machine code
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>
This is now done by the emac driver using a registered nvmem cell.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-mityomapl138.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index b5be51c0451e..5c0a0557a361 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -120,7 +120,6 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)
{
int ret;
const char *partnum = NULL;
- struct davinci_soc_info *soc_info = &davinci_soc_info;
if (!IS_BUILTIN(CONFIG_NVMEM)) {
pr_warn("Factory Config not available without CONFIG_NVMEM\n");
@@ -146,13 +145,6 @@ static void read_factory_config(struct nvmem_device *nvmem, void *context)
goto bad_config;
}
- pr_info("Found MAC = %pM\n", factory_config.mac);
- if (is_valid_ether_addr(factory_config.mac))
- memcpy(soc_info->emac_pdata->mac_addr,
- factory_config.mac, ETH_ALEN);
- else
- pr_warn("Invalid MAC found in factory config block\n");
-
partnum = factory_config.partnum;
pr_info("Part Number = %s\n", partnum);
--
2.18.0
^ permalink raw reply related
* [PATCH 20/28] ARM: davinci: da830-evm: 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-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
^ permalink raw reply related
* [PATCH 22/28] ARM: davinci: dm646x-evm: 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-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
^ permalink raw reply related
* [PATCH 23/28] ARM: davinci: sffsdr: fix the at24 eeprom device name
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>
The currently used 24lc64 i2c device name doesn't match against any
of the devices supported by the at24 driver. Change it to the closest
compatible chip.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/board-sffsdr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c
index e7c1728b0833..f6a4d094cbc3 100644
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@ -100,7 +100,7 @@ static struct at24_platform_data eeprom_info = {
static struct i2c_board_info __initdata i2c_info[] = {
{
- I2C_BOARD_INFO("24lc64", 0x50),
+ I2C_BOARD_INFO("24c64", 0x50),
.platform_data = &eeprom_info,
},
/* Other I2C devices:
--
2.18.0
^ permalink raw reply related
* [PATCH 24/28] ARM: davinci: sffsdr: 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-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
^ 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
* [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
* 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
* 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 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 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 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 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 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 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
* [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][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
* 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 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
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