On Mon, Jun 19, 2023 at 09:30:05AM +0100, Lee Jones wrote:
On Fri, 16 Jun 2023, Charles Keepax wrote:
On Thu, Jun 15, 2023 at 06:11:24PM +0100, Lee Jones wrote:
On Mon, 05 Jun 2023, Charles Keepax wrote:
+static struct i2c_device_id cs42l43_i2c_id[] = {
- { "cs42l43", 0 },
- {}
+}; +MODULE_DEVICE_TABLE(i2c, cs42l43_i2c_id);
Is this required anymore?
I was not aware of it not being required, I think it will still be used for the purposes of module naming. Perhaps someone more knowledgable than me can comment?
Since this table isn't providing any information which cannot be derived from the other (OF, ACPI) tables, the I2C subsystem should be able to obtain it from those sources instead.
Sorry I literally just sent a v4 then saw this email. I will test removing this table and send a v5.
+#if IS_ENABLED(CONFIG_MFD_CS42L43_I2C) +const struct regmap_config cs42l43_i2c_regmap = {
- .reg_bits = 32,
- .reg_stride = 4,
- .val_bits = 32,
- .reg_format_endian = REGMAP_ENDIAN_BIG,
- .val_format_endian = REGMAP_ENDIAN_BIG,
- .max_register = CS42L43_MCU_RAM_MAX,
- .readable_reg = cs42l43_readable_register,
- .volatile_reg = cs42l43_volatile_register,
- .precious_reg = cs42l43_precious_register,
- .cache_type = REGCACHE_RBTREE,
- .reg_defaults = cs42l43_reg_default,
- .num_reg_defaults = ARRAY_SIZE(cs42l43_reg_default),
+}; +EXPORT_SYMBOL_NS_GPL(cs42l43_i2c_regmap, MFD_CS42L43); +#endif
We don't tend to like #ifery in C files.
Why is it required?
And why not just put them were they're consumed?
The trouble is the cs42l43_reg_default array and the array size. There is no good way to statically initialise those two fields from a single array in both the I2C and SDW modules.
Can you have a little think for another way to solve this please?
I will have another go at it, if memory serves the vague options were:
1) this approach 2) some sort of horrible #include to put the defaults array in both modules, although I would really prefer to avoid this one. 3) dynamically allocate the regmap_configs so those two fields can be filled in with non-static data.
If I fail to come up with an option 4 would you prefer 1 or 3? Well or 2 but I really would prefer not to do 2.
Perhaps some simple function headers would help?
You mean add some kernel doc for these functions, right? Assuming that is what you mean, will do.
I'd suggest not using kernel-doc formatting, but that type of thing, yes.
Ok I will remove the kernel doc bits for v5.
Thanks, Charles