On 30/11/2022 10:25, Chuanhong Guo wrote: > Hi! > > On Wed, Nov 30, 2022 at 5:08 PM Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> wrote: >> And that's exactly what I said - the compatibles should not include bus >> information. The bus information comes from... the bus! > > Oh. I thought there will be a conflict if there is a SPI driver and > , say, an I2C driver with the same compatible string. We already have such. For example: adi,adxl312 > >> [...] >>>> >>>> Why unit address is optional? >>> >>> It isn't. I copy-pasted it from led-class-multicolor.yaml and >>> didn't check the exact regex. >>> I'll fix it in the next version. >> >> Make it required and matching your case. > > Got it. > >> [...] >>>>> + default-intensity: >>>>> + description: | >>>>> + An array of 3 integer specifying the default intensity of each color >>>>> + components in this LED. <255 255 255> if unspecified. >>>>> + $ref: /schemas/types.yaml#/definitions/uint32-array >>>>> + minItems: 3 >> [...] >> So this is brightness of each color... > > I don't think so. > See the kernel doc for multicolor LED: > https://docs.kernel.org/leds/leds-class-multicolor.html > This property sets the sysfs file multi_intensity while the > actual LED brightness is controlled with another sysfs > file called 'brightness'. > Setting multi_intensity alone doesn't change the LED > brightness at all. If you had brightness, that would be correct. But you do not have brightness, right? Therefore the final brightness is always: subled[i].brightness = 255 * subled[i].intensity / max_brightness (also 255); Or your bindings are incomplete... Best regards, Krzysztof
