Hi On 2021-05-24 11:27 a.m., Hans de Goede wrote: > Hi, > > On 5/24/21 12:19 PM, Ksr, Prasanth wrote: >> Hi, >> >>> -----Original Message----- From: Hans de Goede >>> <hdegoede@xxxxxxxxxx> Sent: Friday, May 21, 2021 10:25 PM To: >>> Mark Pearson Cc: mgross@xxxxxxxxxxxxxxx; >>> platform-driver-x86@xxxxxxxxxxxxxxx; Bharathi, Divya; Ksr, >>> Prasanth; Dell Client Kernel Subject: Re: [External] Re: [PATCH >>> v2 3/3] platform/x86: think-lmi: Add WMI interface support on >>> Lenovo platforms >>> >>> >>> [EXTERNAL EMAIL] >>> >>> Hi, >>> >>> On 5/21/21 5:55 PM, Mark Pearson wrote: >>> >>> <snip> >>> >>>>>> I know it would make Dell and Lenovo operate differently (I >>>>>> can add that detail to the documentation) but it just feels >>>>>> like a nicer design. >>>>> >>>>> That works for me. Perhaps you can also do a (compile tested >>>>> only) RFC patch for the Dell code to do the same thing >>>>> (replace the memset 0 with the strscpy) to see if the Dell >>>>> folks are ok with also doing things this way ? >>>>> >>>> I'm not hugely comfortable with that. If for some reason it >>>> broke things for Dell customers I wouldn't want to be >>>> responsible :) >>> >>> Right, that is why I suggested making it a RFC patch and I would >>> certainly not apply that patch without it being tested by Dell >>> first. >>> >>> The idea behind the patch is for it to be a way to get a >>> discussion about this started. In my experience patches tend to >>> get more of a reaction then hypothetical discussions about >>> changes :) >>> >>>> I'd rather they made the changes and were able to test it - I >>>> know that's what I'd prefer if it was the other way around. >>>> Apologies if I'm being over cautious! >>> >>> If you don't feel comfortable doing this, that is fine, lets wait >>> what the Dell folks have to say; and if they don't respond I >>> might do a RFC myself. >>> >> >> Ack. We will implement the same from Dell side as well to have >> uniformity and seems nicer from a user point of view rather than >> populating the current_password field again in case of password >> change scenario. > Just as a note, testing this over the weekend, I found that the password change doesn't become active until after a reboot on our systems. So, at least on our systems, copying over strings is pointless. I'll just document the behaviour in the document for our systems, and see if we can improve it in our firmware going forward. Thanks Mark
