linux-kernel - Re: [PATCH] i2c: rk3x: init module as subsys call

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:	Tue, 5 Jan 2016 15:42:32 +0800
From:	"Huang, Tao" <huangtao@...k-chips.com>
To:	Heiko Stuebner <heiko@...ech.de>,
	"jianqun.xu" <jay.xu@...k-chips.com>
Cc:	wsa@...-dreams.de, wdc@...k-chips.com,
	linux-arm-kernel@...ts.infradead.org,
	linux-rockchip@...ts.infradead.org, linux-i2c@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i2c: rk3x: init module as subsys call

Hi, Heiko:

On 2016年01月05日 15:02, Heiko Stuebner wrote:
> Hi Jianqun,
> 
> Am Dienstag, 5. Januar 2016, 11:02:18 schrieb jianqun.xu:
>> From: Xu Jianqun <jay.xu@...k-chips.com>
>>
>> There is a requirement from pmic device, which is on the i2c bus,
>> that the pmic needs to be called earlier then devices powered by
>> the outputs of the pmic, if not, the devices maybe fail to probe.
>>
>> For example, a pmic on i2c0, and touchscreen device on i2c2,
>> i2c0: - pmic(rk818)
>> i2c2: - ts(gt911), powered by rk818 on i2c0
>>
>> The problem will happen if the i2c2 node in dts file is ordered
>> before i2c0 node, then ts(gt911) will be probed before pmic(rk818),
>> since the power from the pmic(rk818) for ts(gt911) hasn't enabled,
>> so ts(gt911) will fail to probe due to the failure of i2c test.
>>
>> But if we set the i2c0 node before i2c2, there is no this issue.
>>
>> The stable way to make sure that pmic can be intalized before other
>> peripher devices is to make the pmic module be subsys call, the i2c
>> module need to be subsys call firstly.
> 
> I do believe that came up in the past already and the direction from then 
> was (and most likely still is) that drivers should make use of the probe-
> deferral mechanism instead of wiggling with the initcall ordering.


I don't think this is a good idea. This will trigger a lots of init call
failed. Before pmic init, all i2c device driver transmit will failed,
and because i2c is slow bus, and i2c transmit may failed by other
reasons, so the i2c driver and i2c device driver will try many times to
make sure the transmit completion. These unnecessary transmission will
make Linux boot very slow.

I2C bus should be subsys, and we can easy resolve this problem, why we
depends on a complicated and slow implementation?

> 
> Your touchscreen will have a "xyz-supply" property and I think the 
> regulator-framework should already emit a -EPROBE_DEFER at regulator_get, 
> when the regulator is specified but not available yet.

Unfortunately, mostly driver do not support regulator api. They are
suppose power is on.

Thanks.
Huang, Tao

> 
> 
> Heiko
> 
>>
>> Signed-off-by: Xu Jianqun <jay.xu@...k-chips.com>
>> ---
>>  drivers/i2c/busses/i2c-rk3x.c | 12 +++++++++++-
>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
>> index c1935eb..00e5959 100644
>> --- a/drivers/i2c/busses/i2c-rk3x.c
>> +++ b/drivers/i2c/busses/i2c-rk3x.c
>> @@ -1037,7 +1037,17 @@ static struct platform_driver rk3x_i2c_driver = {
>>  	},
>>  };
>>
>> -module_platform_driver(rk3x_i2c_driver);
>> +static int __init rk3x_i2c_init(void)
>> +{
>> +	return platform_driver_register(&rk3x_i2c_driver);
>> +}
>> +subsys_initcall(rk3x_i2c_init);
>> +
>> +static void __exit rk3x_i2c_exit(void)
>> +{
>> +	platform_driver_unregister(&rk3x_i2c_driver);
>> +}
>> +module_exit(rk3x_i2c_exit);
>>
>>  MODULE_DESCRIPTION("Rockchip RK3xxx I2C Bus driver");
>>  MODULE_AUTHOR("Max Schwarz <max.schwarz@...ine.de>");
> 
> 
> 
> 


--
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/