On 2024/7/8 15:32, Krzysztof Kozlowski wrote:
On 08/07/2024 08:32, Yang Li wrote:
在 2024/7/8 14:11, Krzysztof Kozlowski wrote:
On 08/07/2024 08:04, Yang Li wrote:
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - amlogic,chip-enable-gpios
+ - amlogic,bt-enable-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ wcn_pwrseq {
No underscores in node names, generic node names.
There is no device as "pwrseq". I also do not get what "wcn" means here.
Yes, I understand.
Can I change "wcn_pwrseq" to "pmu", and do I need to change the binding
What is pmu for your device? What is this device in the first place you
are documenting? Where is the datasheet?
^_^ Well, You are right, the "pmu" wasn't really fit in here.
I'd like to explain the current usage first, and could you please give
me a suggestion?
This module(pwrseq) used to power on Bluetooth & Wi-Fi combo chip, both
Bluetooth and
Wi-Fi driver need to control "chip-en-gpios" pins, so we introduced the
power sequence module.
What should we call it in this case?
Sorry, you describe driver, not a device.
That would be a no-go for entire binding. Please describe the hardware,
not what you want to achieve in Linux drivers.
W155s2 is a Bluetooth and WiFi combination chip. Bluetooth requires the
bt-en pin to be pulled up, the chip-en pin to be pulled up, and the
32.768KHz clock. WiFi requires the chip-en pin to be pulled up, and the
32.768KHz clock. It can be seen that Bluetooth and WiFi are coupled to
the chip-en pin and the 32.768KHz clock. When Bluetooth and WiFi are
working at the same time, no matter which one is turned off, it will
affect the other device. Therefore, a pwrseq device is now abstracted to
manage the chip-en pin, bt-en pin, and the 32.768KHz clock.
There is currently no matching device name for the pwrseq composite device.
Could you please give me some advice?
Best regards,
Krzysztof
