linux-kernel - Re: [PATCH V1 1/1] USB: serial: f81232: fix incomplete serial port generation

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8af5eb5f-0adb-4ea5-a4d5-554a7e883570@fintek.com.tw>
Date: Wed, 15 Oct 2025 10:24:56 +0800
From: Peter Hong <peter_hong@...tek.com.tw>
To: Johan Hovold <johan@...nel.org>
CC: <gregkh@...uxfoundation.org>, <linux-usb@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <tom_tsai@...tek.com.tw>,
        <yu_chen@...tek.com.tw>, <hpeter+linux_kernel@...il.com>
Subject: Re: [PATCH V1 1/1] USB: serial: f81232: fix incomplete serial port
 generation

Hi Johan,

Johan Hovold 於 2025/10/14 下午 11:36 寫道:
> On Wed, Oct 08, 2025 at 10:38:58AM +0800, Ji-Ze Hong (Peter Hong) wrote:
>> The Fintek F81532A/534A/535/536 family relies on the
>> F81534A_CTRL_CMD_ENABLE_PORT (116h) register during initialization to
>> both determine serial port status and control port creation. If the
>> driver experiences fast load/unload cycles, the device state may becomes
>> unstable, resulting in the incomplete generation of serial ports.
> Do I understand correctly that you're only seeing this issue if you're
> unloading and reloading the module (or rebinding the driver through
> sysfs)?

Yes, this issue has only been observed and reported during module unload
and reload operations currently.

>> Performing a dummy read operation on the register prior to the initial
>> write command resolves the issue. This clears the device's stale internal
>> state. Subsequent write operations will correctly generate all serial
>> ports.
> Does this mean that the retry loop is no longer needed? Can it now be
> removed in either or both accessor functions perhaps?

OK, we'll test the loop removal in the accessor. If successful, we'll prepare
and send V2.


Thanks,