linux-kernel - Re: [PATCH] wifi: rtl8xxxu: fix LED control code of RTL8192FU

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]

Message-ID: <20230911144155.5871-1-zenmchen@gmail.com>
Date:   Mon, 11 Sep 2023 22:41:45 +0800
From:   xx777 <zenmchen@...il.com>
To:     zenmchen@...il.com
Cc:     Jes.Sorensen@...il.com, kvalo@...nel.org,
        linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
        pkshih@...ltek.com, rtl8821cerfe2@...il.com
Subject: Re: [PATCH] wifi: rtl8xxxu: fix LED control code of RTL8192FU

Bitterblue Smith <rtl8821cerfe2@...il.com> wrote：
>
> Can you explain in the commit message why you changed the
> LED_ON and LED_OFF branches? It's not obvious to me and they
> don't have anything to do with the hardware-controlled blinking.
>

Hi,

Sorry that I didn't explain this clearly.
After some researches these days, I came to some conclusions:

1. The LED of MERCURY MW310UH and COMFAST CF-826F seems to be controlled by
   REG_LEDCFG1, and currently rtl8xxxu controls the LED through writing
   some suitable values to this register, so MW310UH and CF-826F work fine
   with rtl8xxxu.

2. The LED of ASUS USB-N13 C1 seems to be controlled by another register 
   "REG_LEDCFG0" for unknown reason, so when I write 1 or 2 to 
   /sys/class/leds/rtl8xxxu-usbX-Y/brightness, the LED doesn't turn on 
   or blink because the register "REG_LEDCFG0" is not filled with a suitable 
   value, This is why I changed the LED_ON and LED_OFF branches.

I will modify the commit message in the next version of patch, thanks.