Hi!

On 2021-01-14 19:43, Vadim Pasternak wrote:

Hi Peter and Wolfram,

Thank you for your comments.

quoted

-----Original Message-----
From: Peter Rosin <redacted>
Sent: Thursday, January 14, 2021 9:49 AM
To: wsa@the-dreams.de; Vadim Pasternak <vadimp@nvidia.com>; linux-
i2c@vger.kernel.org
Subject: Re: [Re-send: PATCH i2c-next 5/6] i2c: mux: mlxcpld: Extend driver to
support word address space devices

Hi!

On 2021-01-12 11:11, wsa@the-dreams.de wrote:

quoted

quoted

Wolfram, is there a better way to get something stable for user space
to interact with? Is there maybe a way to do this with aliases or something?
Setting up an ad-hoc scheme for forcing the adapter IDs feels a bit

outdated.

quoted

Yeah, it feels rightfully outdated IMO. Bringing such policy into the
kernel is frowned upon. I think the proper way is a udev rule to act
on the newly created I2C adapter. This even could provide a really
stable symlink for userspace to consume. The above scheme is only
stable per "block" but inside the block, there is still randomness. Or?

Right, that makes sense. Thanks! Vadim, is there any reason to not solve this
with udev? Doing that with care could perhaps provide stable names even if
you swap slots?

Yes, I can manage it by udev and provide some names like "i2c-lc1-fpga1",
which maybe will be more clear for user, then name like "i2c-132".

I have another, not user space problem and maybe you can
suggest some solution.

In line card driver I planned to create I2C infrastructure for the
specific line card, like:

static int mlxreg_lc_chan[] = {
	0x04, 0x05, 0x06, 0x07, 0x08, 0x10, 0x20, 0x21, 0x22, 0x23, 0x40, 0x41,
	0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d,
	0x4e, 0x4f
};

static struct mlxcpld_mux_plat_data mlxreg_lc_mux_data[] = {
	{
		.chan_ids = mlxreg_lc_chan,
		.num_adaps = ARRAY_SIZE(mlxreg_lc_chan),
		.sel_reg_addr = MLXREG_LC_CHANNEL_I2C_REG,
		.reg_size = 2,
	},
};

	mlxreg_lc->mux = platform_device_register_resndata(dev, "i2c-mux-mlxcpld", parent_nr,
							   NULL, 0, &mlxreg_lc_mux_data,
							   sizeof(mlxreg_lc_mux_data));

And after this infrastructure is ready - to attach from this drive line
card devices from 'i2c_board_info', like:

static struct i2c_board_info mlxreg_lc_main_pwr_devices[] = {
	{
		I2C_BOARD_INFO("mp2975", 0x62),
	},
	{
		I2C_BOARD_INFO("mp2975", 0x64),
	},
	{
		I2C_BOARD_INFO("max11603", 0x6d),
	},
	{
		I2C_BOARD_INFO("lm25066", 0x15),
	},
};

static struct mlxreg_hotplug_device mlxreg_lc_main_pwr_brdinfo[] = {
	{
		.brdinfo = &mlxreg_lc_main_pwr_devices[0],
		.nr = 4,
	},
	{
		.brdinfo = &mlxreg_lc_main_pwr_devices[1],
		.nr = 4,
	},
	{
		.brdinfo = &mlxreg_lc_main_pwr_devices[2],
		.nr = 5,
	},
	{
		.brdinfo = &mlxreg_lc_main_pwr_devices[3],
		.nr = 6,
	},
};

Where the above 'nr's are from 'mlxreg_lc_chan'.

And then create with i2c_new_client_device() all the above devices from
workqueue, which will be running until all the 'mlxreg_lc_chan' related
adapters are created.
With forcing base nr, I know the number of last nr, which should be
created by "i2c-mux-mlxcpld".

Without it I'll need some ability to find with nrs have been created by
"i2c-mux-mlxcpld".
Do you have any suggestions for that?

I understand that I can also do it through udev, but I'd prefer to create
all on-board (line card) devices from the kernel, if possible.

You could add a callback function to struct mlxcpld_mux_plat_data, and have the
driver call you back with the mapping so that you know what adapter ID you got
for each platform data (or channel if needed) you instantiate.

Would that do it?

Cheers,
Peter