On Fri, Oct 04, 2024 at 07:59:41PM GMT, Bartosz Golaszewski wrote: > On Fri, Oct 4, 2024 at 7:31 PM Bjorn Andersson <andersson@xxxxxxxxxx> wrote: > > > > > > > > + /* > > > + * Old device trees for some platforms already define wifi nodes for > > > + * the WCN family of chips since before power sequencing was added > > > + * upstream. > > > + * > > > + * These nodes don't consume the regulator outputs from the PMU and > > > + * if we allow this driver to bind to one of such "incomplete" nodes, > > > + * we'll see a kernel log error about the indefinite probe deferral. > > > + * > > > + * Let's check the existence of the regulator supply that exists on all > > > + * WCN models before moving forward. > > > + * > > > + * NOTE: If this driver is ever used to support a device other than > > > + * a WCN chip, the following lines should become conditional and depend > > > + * on the compatible string. > > > > What do you mean "is ever used ... other than WCN chip"? > > > > This driver was released as part of v6.11 and so far (until v6.12) is > only used to support the WCN chips. That's not to say that it cannot > be extended to support more hardware. I don't know how to put it in > simpler words. > > > This driver and the power sequence framework was presented as a > > completely generic solution to solve all kinds of PCI power sequence > > problems - upon which the WCN case was built. > > > > I never presented anything as "completely generic". You demanded that > I make it into a miraculous catch-all solution. That is correct. I strongly requested that you would come up with a solution that worked for BOTH (all two!) use cases we had on the table for PCI power sequencing. > I argued that there's no such thing and this kind of attitude is > precisely why it's so hard to get anything done in the kernel. I'm sorry that you feel it's my attitude that's the problem here. I don't think that is what make this hard, but rather the technical challenges of the problem itself. Regards, Bjorn
