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, 3 Jun 2021 00:30:45 +0900
From:   Chanwoo Choi <cwchoi00@...il.com>
To:     Stephan Gerhold <stephan@...hold.net>
Cc:     Chanwoo Choi <cw00.choi@...sung.com>,
        MyungJoo Ham <myungjoo.ham@...sung.com>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Nikita Travkin <nikita@...n.ru>,
        ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH v3 2/3] extcon: sm5502: Refactor driver to use
 chip-specific struct

On 21. 6. 3. 오전 12:20, Stephan Gerhold wrote:
> On Thu, Jun 03, 2021 at 12:13:18AM +0900, Chanwoo Choi wrote:
>> On 21. 6. 2. 오전 5:00, Stephan Gerhold wrote:
>>> Prepare for supporting SM5504 in the extcon-sm5502 driver by replacing
>>> enum sm5504_types with a struct sm5504_type that stores the chip-specific
>>> definitions. This struct can then be defined separately for SM5504
>>> without having to add if (type == TYPE_SM5504) everywhere in the code.
>>>
>>> Signed-off-by: Stephan Gerhold <stephan@...hold.net>
>>> ---
>>> Changes in v3: New patch to simplify diff on next patch
>>> ---
>>>    drivers/extcon/extcon-sm5502.c | 64 +++++++++++++++++++++-------------
>>>    drivers/extcon/extcon-sm5502.h |  4 ---
>>>    2 files changed, 40 insertions(+), 28 deletions(-)
>>>
>>> diff --git a/drivers/extcon/extcon-sm5502.c b/drivers/extcon/extcon-sm5502.c
>>> index 9f40bb9f1f81..951f6ca4c479 100644
>>> --- a/drivers/extcon/extcon-sm5502.c
>>> +++ b/drivers/extcon/extcon-sm5502.c
>>> @@ -40,17 +40,13 @@ struct sm5502_muic_info {
>>>    	struct i2c_client *i2c;
>>>    	struct regmap *regmap;
>>> +	const struct sm5502_type *type;
>>>    	struct regmap_irq_chip_data *irq_data;
>>> -	struct muic_irq *muic_irqs;
>>> -	unsigned int num_muic_irqs;
>>>    	int irq;
>>>    	bool irq_attach;
>>>    	bool irq_detach;
>>>    	struct work_struct irq_work;
>>> -	struct reg_data *reg_data;
>>> -	unsigned int num_reg_data;
>>> -
>>>    	struct mutex mutex;
>>>    	/*
>>> @@ -62,6 +58,17 @@ struct sm5502_muic_info {
>>>    	struct delayed_work wq_detcable;
>>>    };
>>> +struct sm5502_type {
>>> +	struct muic_irq *muic_irqs;
>>> +	unsigned int num_muic_irqs;
>>> +	const struct regmap_irq_chip *irq_chip;
>>> +
>>> +	struct reg_data *reg_data;
>>> +	unsigned int num_reg_data;
>>> +
>>> +	int (*parse_irq)(struct sm5502_muic_info *info, int irq_type);
>>> +};
>>> +
>>>    /* Default value of SM5502 register to bring up MUIC device. */
>>>    static struct reg_data sm5502_reg_data[] = {
>>>    	{
>>> @@ -502,11 +509,11 @@ static irqreturn_t sm5502_muic_irq_handler(int irq, void *data)
>>>    	struct sm5502_muic_info *info = data;
>>>    	int i, irq_type = -1, ret;
>>> -	for (i = 0; i < info->num_muic_irqs; i++)
>>> -		if (irq == info->muic_irqs[i].virq)
>>> -			irq_type = info->muic_irqs[i].irq;
>>> +	for (i = 0; i < info->type->num_muic_irqs; i++)
>>> +		if (irq == info->type->muic_irqs[i].virq)
>>> +			irq_type = info->type->muic_irqs[i].irq;
>>> -	ret = sm5502_parse_irq(info, irq_type);
>>> +	ret = info->type->parse_irq(info, irq_type);
>>
>> Looks good to me. But there is only one comment.
>> Need to check the 'parse_irq' as following:
>>
>> If you agree this suggestion, I'll apply with following changes by myself:
>>
>> 	if (!info->type->parse_irq) {
>> 		dev_err(info->dev, "failed to handle irq due to parse_irq\n",
>> 		return IRQ_NONE;
>> 	}
>>
>>
> 
> This condition should be impossible, since .parse_irq is set for both
> SM5502 and SM5504:
> 
> static const struct sm5502_type sm5502_data = {
> 	/* ... */
> 	.parse_irq = sm5502_parse_irq,
> };
> 
> static const struct sm5502_type sm5504_data = {
> 	/* ... */
> 	.parse_irq = sm5504_parse_irq,
> };
> 
> Which failure case are you trying to handle with that if statement?

There is not failure case of this patchset. But, this refactoring 
suggestion has the potential problem without checking whether mandatory 
function pointer is NULL or not. When adding new chip by using this 
driver, the author might have the human error without parse_irq 
initialization even if the mandatory.

> 
> Thanks!
> Stephan
> 


-- 
Best Regards,
Samsung Electronics
Chanwoo Choi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ