Skip to contentSkip to conversation

ARM: pxa: stargate2: use device properties for at24 eeprom

PATCH RESEND Applied Bartosz Golaszewski 3 participants 5 messages Apr 4, 2018 – Apr 8, 2018

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH RESEND 1/1 ARM: pxa: stargate2: use device properties for at24 eeprom

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.

---
NOTE: resending with correct e-mail address for Jonathan Cameron.

 arch/arm/mach-pxa/stargate2.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
arch/arm/mach-pxa/stargate2.c +5 -5
index df62bb23dbee..bbea5fa9a140 100644
@@ -27,11 +27,11 @@
 
 #include <linux/platform_data/i2c-pxa.h>
 #include <linux/platform_data/pcf857x.h>
-#include <linux/platform_data/at24.h>
 #include <linux/smc91x.h>
 #include <linux/gpio/machine.h>
 #include <linux/gpio.h>
 #include <linux/leds.h>
+#include <linux/property.h>
 
 #include <asm/types.h>
 #include <asm/setup.h>
@@ -795,9 +795,9 @@ static struct pcf857x_platform_data platform_data_pcf857x = {
 	.context = NULL,
 };
 
-static struct at24_platform_data pca9500_eeprom_pdata = {
-	.byte_len = 256,
-	.page_size = 4,
+static const struct property_entry pca9500_eeprom_properties[] = {
+	PROPERTY_ENTRY_U32("pagesize", 4),
+	{ }
 };
 
 /**
@@ -935,7 +935,7 @@ static struct i2c_board_info __initdata stargate2_i2c_board_info[] = {
 	}, {
 		.type = "24c02",
 		.addr = 0x57,
-		.platform_data = &pca9500_eeprom_pdata,
+		.properties = pca9500_eeprom_properties,
 	}, {
 		.type = "max1238",
 		.addr = 0x35,
Signature · 1 line
2.16.3
Acked-by on v1 1/1
#1 lore raw
Quoted 10 lines · Bartosz Golaszewski

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.

Looks sensible to me.

Will be a while before I can test but this looks safe enough..

Quoted 48 lines

---
NOTE: resending with correct e-mail address for Jonathan Cameron.

arch/arm/mach-pxa/stargate2.c | 10 +++++-----

1 file changed, 5 insertions(+), 5 deletions(-)
arch/arm/mach-pxa/stargate2.c +4 -4
index df62bb23dbee..bbea5fa9a140 100644
@@ -27,11 +27,11 @@
 
 #include <linux/platform_data/i2c-pxa.h>
 #include <linux/platform_data/pcf857x.h>
-#include <linux/platform_data/at24.h>
 #include <linux/smc91x.h>
 #include <linux/gpio/machine.h>
 #include <linux/gpio.h>
 #include <linux/leds.h>
+#include <linux/property.h>
 
 #include <asm/types.h>
 #include <asm/setup.h>
@@ -795,9 +795,9 @@ static struct pcf857x_platform_data
 platform_data_pcf857x = {
 	.context = NULL,
 };
 
-static struct at24_platform_data pca9500_eeprom_pdata = {
-	.byte_len = 256,
-	.page_size = 4,
+static const struct property_entry pca9500_eeprom_properties[] = {
+	PROPERTY_ENTRY_U32("pagesize", 4),
+	{ }
 };
 

/**

arch/arm/mach-pxa/stargate2.c +1 -1
@@ -935,7 +935,7 @@ static struct i2c_board_info __initdata
 stargate2_i2c_board_info[] = {
 	}, {
 		.type = "24c02",
 		.addr = 0x57,
-		.platform_data = &pca9500_eeprom_pdata,
+		.properties = pca9500_eeprom_properties,
 	}, {
 		.type = "max1238",
		.addr = 0x35,
Signature · 1 line
Sent from my Android device with K-9 Mail. Please excuse my brevity.
maintainer
#2 lore raw
In reply to Bartosz Golaszewski
Quoted 8 lines · Bartosz Golaszewski

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.

Hi Bartosz,

I'd like a little explanation for the last sentence. Are you implying that ac24.c is using the "type" field, and if so could you point me to the correct line, because I was under the impression a property called "size" is used for byte_len value ... ?

Cheers.

--
Robert

#3 lore raw

2018-04-04 21:44 GMT+02:00 Robert Jarzmik <[email protected]>:

Quoted 10 lines
Quoted 8 lines · Bartosz Golaszewski

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.

Quoted 7 lines

Hi Bartosz,

I'd like a little explanation for the last sentence. Are you implying that ac24.c is using the "type" field, and if so could you point me to the correct line, because I was under the impression a property called "size" is used for byte_len value ... ?

Yes, it does use the type field from i2c_board_info implicitly over i2c-core. The type field is copied over to client->name and then is matched against the i2c ID table from which we get the associated chip data (unless the type is "at24") containing the size and flags.

Hope that helps.

Bartosz

maintainer Applied
#4 lore raw
Quoted 6 lines · Bartosz Golaszewski

2018-04-04 21:44 GMT+02:00 Robert Jarzmik <[email protected]>:

Quoted 1 line

Bartosz Golaszewski <[email protected]> writes:

Yes, it does use the type field from i2c_board_info implicitly over i2c-core. The type field is copied over to client->name and then is matched against the i2c ID table from which we get the associated chip data (unless the type is "at24") containing the size and flags.

Ah yes, the "struct i2c_device_id at24_ids" part, I see.

Applied to pxa/for-next, thanks.

Signature · 1 line
Robert