09:05 <konradybcio> W=1 is useful together with a path

09:05 <konradybcio> so e.g. make ARCH=arm64 LLVM=1 -j16 drivers/soc/

14:06 <mgonzalez> lumag: I've been working on the tdp158 submission, and I realize that despite all my efforts to explain how the device can be set up, I seem to be failing to get the message across to mripard ?

14:07 <mgonzalez> Would it help at all if I included code in the driver that queried the device over I2C to get the device ID? (This would prove that the driver & HW do handle I2C accesses)

14:09 <mripard> I would suggest to focus on being less antagonizing. It would help you, and it's not the first time we have that discussion.

14:10 <mripard> claiming you made efforts when you completely ignored mails from both lumag and I for example is a bit ridiculous

14:11 <mgonzalez> Iwhat?!

14:12 <mgonzalez> Oh because I have not replied yet?

14:12 <mgonzalez> No, I have read them several times to understand what the issue is

14:12 <mgonzalez> And I'm addressing them by changing the code and making a PoC

14:13 <mgonzalez> I was AFK for a week

14:14 <mgonzalez> The binding issue was low-hanging fruit since Conor had already stated he didn't mind one way or the other

14:16 <mripard> The binding is the only hanging fruit right now

14:16 <mgonzalez> No, I meant the reg property

14:16 <mgonzalez> And the PoC will address your other concern of backwards compat

14:17 <mgonzalez> And for the record, there is another similar device in mainline, I'm willing to bet it hasn't received the same scrutiny, but no matter, I'm getting close to a solution

14:19 <mgonzalez> mripard: read between the lines, adding I2C accesses in the driver wouldn't be useful?

14:19 <mgonzalez> s/read/reading

14:21 <mgonzalez> trying again: if I read between the lines, you're implying that adding I2C accesses in the driver would not bring anything?

14:21 <mgonzalez> Because all that matters is how to address the I2C vs pin strap issue?

14:30 <mgonzalez> mripard: I had not checked my email before sending my IRC message

14:30 <mgonzalez> It was not done as a sleight to you

14:35 <mgonzalez> s/sleight/slight

14:39 <aka_[m]> <konradybcio> "W=1 is useful together with a..." <- danke schön

17:35 <mgonzalez> lumag: I think I have addressed all outstanding issues for tdp158?

17:36 <mgonzalez> I don't think it makes sense to add the platform driver stub if it's not used, it just makes the driver more complex for nothing

17:36 <mgonzalez> also, I don't think I should add the device query debug code?

17:38 <lumag> mgonzalez, as I wrote bindings are for the hardware, the driver is a separate topic. You don't have a device that uses pin-straps to configure TDP158. Also the straps and non-straps setup are mutually exclusive.

17:38 <mgonzalez> I don't know what to take away from that?

17:39 <mgonzalez> Basically what I'm saying is "what I proposed works, so I don't understand what mripard is asking for"

17:41 <mgonzalez> tfp410 handles pinstrap mode & I2C mode the same way I guess

17:42 <mgonzalez> lumag: except that they force some parameters when in I2C mode

17:44 <lumag> mgonzalez, again, forget about the driver when speaking about bindings.

17:44 <lumag> I know it's hard. I also fail to do it sometimes.

17:44 <mgonzalez> OK no driver, no driver, no driver

17:44 <lumag> Thanks :-)

17:45 <lumag> So, I looked at tf410. The bindings clearly specify that it is either I2C or it is the pin-strap mode (via the if).

17:45 <mgonzalez> device has same wires pinstrapped vs programmable

17:45 <mgonzalez> No, the if just sets some stuff for the driver

17:45 <mgonzalez> They cheated

17:45 <mgonzalez> Basically, they're saying "if we're in I2C mode, don't hardcode skew"

17:46 <mgonzalez> That's not saying "device must be pinstrapped or I2C"

17:46 <mgonzalez> Also there's no way to force reg to be absent in the pinstrapped mode

17:46 <lumag> It is implied via the else branch

17:46 <mgonzalez> So it's all fluff

17:47 <mgonzalez> I can write in the description that reg is required for I2C, and must be absent for pinstrapped

17:47 <lumag> I'd prefer a clear oneOf: with two cases, but it seems DT maintainers were fine with that if (or it's just nobody cared).

17:47 <mgonzalez> But it's not enforced by the compiler, it would be a convention

17:48 <lumag> I think that since you really can test and support the i2c mode, ignore the pin-strapped mode. Write about it in the commit message, that should be enough.

17:49 <lumag> mripard, do you have any concerns from your side/

17:49 <mgonzalez> famous last words

17:54 <mgonzalez> It's 8pm in France, not sure mripard will see this

17:55 <mgonzalez> Basically, I need to beef up the commit message on patch 1 to explain the 2 possible setups and how my binding addresses both?

17:55 <mgonzalez> lumag: is that it?

17:56 <lumag> mgonzalez, or that you leave the pin-strapping as a place for improvement

17:56 <mgonzalez> This makes no sense to me

17:57 <mgonzalez> Pin strapping means "everything is hard-coded". Thus there is NOTHING about it in a binding

18:01 <mgonzalez> lumag: I will send an update tomorrow, probably. Or maybe I should wait for mripard's feedback because basically, nothing changes in my code

21:32 <jessica_24> hey, is there any API that will let me re-probe drivers within the deferred probe list? I'm seeing `driver_deferred_probe_trigger()` as an option, but looks like it's not meant to be used outside the base device driver code

23:11 <steev> lumag: where is your ath10k board-2.bin from? my c630 doesn't seem to have a board-2.bin that has the Lenovo_C630 variant in it

23:15 <steev> ah, it's in codelinaro, sorry