Hi! > > > As such the pattern sequence provided to hw_pattern looks to be the > > > smae, but I don't see that it can be made compatible. > > > > > > > Can I get either patch to disable pattern infrastructure for now or to > > > > get it compatible? > > > > > > > > > > I'd be happy to get this updated to your liking, but this was one of the > > > drivers we discussed when we introduced the pattern trigger and led to > > > the conclusion that we need the ability to do hw-specific patterns. > > > > > > As such this document provides the hardware specific documentation, as > > > we describe under "hw_pattern" in > > > Documentation/ABI/testing/sysfs-class-led-trigger-pattern. > > > > > > Please advice on what you would like me to do. > > > > I'd like you to use same format leds-trigger-pattern describes. > > > > If someone passes "255 500 0 500", that's requesting gradual transitions and > > your hw can not do that. You return -EINVAL. > > > > If someone wants that kind of blinking, they need to pass "255 0 255 500 0 0 0 500". > > > > So the section under hw_pattern in sysfs-class-led-trigger-pattern that > says: > > "Since different LED hardware can have different semantics of > hardware patterns, each driver is expected to provide its own > description for the hardware patterns in their documentation > file at Documentation/leds/." > > That doesn't apply to this piece of hardware & driver? It applies: since your hardware can not do arbitrary patterns, you need description of what kinds of patterns it can do. But you should still use compatible format, so that pattern that is valid for hw_pattern file is valid for pattern file, too, and produces same result. If you believe documentation implies something else, it may need to be clarified. Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates.
Attachment:
signature.asc
Description: Digital signature
