linux-kernel - Re: [PATCH v7] usb: common: usb-conn-gpio: Set last role to unknown before initial detection

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] [day] [month] [year] [list]

Message-ID: <3a90900f-bf60-0b9e-43ab-451264785cba@quicinc.com>
Date:   Thu, 15 Jun 2023 23:41:47 +0530
From:   Prashanth K <quic_prashk@...cinc.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7] usb: common: usb-conn-gpio: Set last role to unknown
 before initial detection



On 15-06-23 08:35 pm, Greg Kroah-Hartman wrote:
> On Thu, Jun 15, 2023 at 08:28:13PM +0530, Prashanth K wrote:
>>
>>
>> On 15-06-23 08:06 pm, Greg Kroah-Hartman wrote:
>>> On Thu, Jun 15, 2023 at 07:52:32PM +0530, Prashanth K wrote:
>>>>
>>>> In that case, can I resubmit v1 of this patch again, where I have used a
>>>> macro in usb-conn-gpio driver ? something like this.
>>>>
>>>> @@ -27,6 +27,8 @@
>>>>    #define USB_CONN_IRQF	\
>>>>    	(IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT)
>>>>
>>>> +#define USB_ROLE_UNKNOWN (USB_ROLE_NONE -1)
>>>
>>> Are you referencing an existing enum here and assuming it is a specific
>>> value?
>>
>> I' not assuming UBS_ROLE_NONE to be a specific value, but I want an integer
>> (for macro) which is not equal to USB_ROLE_NONE/DEVICE/HOST, that's why I'm
>> using (USB_ROLE_NONE - 1), assuming enumerators NONE, DEVICE & HOST will be
>> having adjacent integer values. Wouldn't that help?
> 
> You can't do "math" on an enumerated type and expect the result to be
> anything constant over time.
> 
> And yes, you can hope that enumerated types are sequential, and the spec
> says so, but please never rely on that as what happens if someone adds a
> new one in the list without you ever noticing it.
> 
> Pleasae treat enumerated types as an opaque thing that you never know
> the real value of, it's a symbol only.
> 
> thanks,
> 
> greg k-h

Then we can go ahead a different approach using a flag. But that would 
require us to add a new member to usb_conn_info struct. What do you suggest?

@@ -42,6 +42,7 @@ struct usb_conn_info {

         struct power_supply_desc desc;
         struct power_supply *charger;
+       bool initial_det;
  };

  /*
@@ -86,11 +87,13 @@ static void usb_conn_detect_cable(struct work_struct 
*work)
         dev_dbg(info->dev, "role %s -> %s, gpios: id %d, vbus %d\n",
                 usb_role_string(info->last_role), 
usb_role_string(role), id, vbus);

-       if (info->last_role == role) {
+       if (!info->initial_det && (info->last_role == role)) {
                 dev_warn(info->dev, "repeated role: %s\n", 
usb_role_string(role));
                 return;
         }

+       info->initial_det = false;
+
         if (info->last_role == USB_ROLE_HOST && info->vbus)
                 regulator_disable(info->vbus);

@@ -258,6 +261,7 @@ static int usb_conn_probe(struct platform_device *pdev)
         device_set_wakeup_capable(&pdev->dev, true);

         /* Perform initial detection */
+       info->initial_det = true;
         usb_conn_queue_dwork(info, 0);

Regards,
Prashanth K