lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 23 Aug 2012 16:28:52 +0800
From:	Feng Tang <feng.tang@...el.com>
To:	Alexander Stein <alexander.stein@...tec-electronic.com>
Cc:	<linux-i2c@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	"Jean Delvare (PC drivers, core)" <khali@...ux-fr.org>,
	"Ben Dooks (embedded platforms)" <ben-linux@...ff.org>,
	Tomoya MORINAGA <tomoya.rohm@...il.com>
Subject: Re: i2c-eg20t: regression since i2c_add_numbered_adapter change

Hi,

On Wed, 22 Aug 2012 11:17:51 +0200
Alexander Stein <alexander.stein@...tec-electronic.com> wrote:

> Hello,
> 
> Am Mittwoch, 22. August 2012, 16:04:39 schrieb Feng Tang:
> > > Why use a fixed one? Give the driver (and maybe every i2c bus driver) a parameter which sets the base bus number it should use.
> > > E.g. i2c-eg20t.base-bus-num=2 so it will register the bus numbers starting from 2. If this parameter is unset. It would use the first free one, thus simply using i2c_add_adapter.
> > 
> > The reason we need a fixed number is it is easier for platform code
> > which needs to register dozens of i2c devices to different controllers
> > with i2c_register_board_info, and they need provide a bus number for
> > each i2c device, this _binding_ info is not detectable but have to
> > be fixed.
> 
> Yes, I'm aware of that. With "Why use a fixed one?" I meant why hard-code it into the driver. I should be changeable.
> Because this is/was not possible in general to use i2c_register_board_info, so we used an echo to /sys/bus/i2c/devices/i2c-0/new_device or /sys/bus/i2c/devices/i2c-1/new_device.

Yeah, our EG20T kernel used to use the same "echo /sys/bus/i2c/devices/i2c-x/new_device"
way, but we found out it is not convenient for:
1. needs extra user space script, why not make it just work in kernel after
boot? We have several i2c devices like touchscreen/radio which we wants them
just work without depending user space action.
2. The i2c bus number is not fixed, which make the user space script even
harder, as that number depends whether we compile into kernel all the i2c
controllers (eg20t and isch) and whether these driver are compiled as
modules and their loading order.

Thus we come out with this fixed bus number registering.

As I said before, either your module parameter "base_bus_num" solution
or my fixed bus number offset are ok to me. Will you cook a patch?

Thanks,
Feng

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ