09:41 <mani_s> lumag, It depends on what kind of M.2 card it is. If it follows the PCIe CEM spec, then it should be described as it is in the PCIe child node under bridge

15:32 <int-hellhound> hi guys. im trying to port sm8635 platform to the mainline, and im facing few issues with tlmm. for some reason, when i set 179 '.ngpios', boot crashes on pinctrl, but if i lower that value by 1, it loads as nothing happened. there are total of 179 pins if i got it right (0-178, last of which ufs_reset one)

15:34 <ungeskriptet> int-hellhound: are you using the sm8650 gpio driver? I'm not sure how similar sm8650 and sm8635 are but maybe you can make use of the sm8650 driver

15:34 <ungeskriptet> similar to how sdm670 is using the sdm845 driver

15:35 <int-hellhound> ungeskriptet: no, im using upstreamed driver from android

15:35 <krzk> konradybcio: "Do you reject" is a YES/NO question. I don't get why you answer with convoluted statement without actual action/decision/opinion.

15:35 <krzk> Say explicitly: NO, I disagree, commit msg should be silent on breaking platforms so all users will be surprised and annoyed.

15:36 <krzk> or YES, commit msg should be updated as krzk asks....

15:36 <int-hellhound> by upstreamed, i mean i ported it. im new to this thing, so sorry if i can make some mistakes

15:36 <krzk> wait - s/krzk/rob/ :)

15:36 <krzk> It's Rob which asked that

15:37 <krzk> But I second that in that sc7280 and every other thread

15:38 <int-hellhound> i can send my repo with some stuff that already been done.

15:38 <konradybcio> krzk the answer is a Future<T> and is awaiting opinions of people that know pcie a little better..

15:39 <krzk> konradybcio: that's not the anwser to yes/no question. It's not an answer at all, considering patch needs yes/no NOW, not in future.

15:40 <krzk> Rob had clear request there and I really do not understand why it cannot be complied with.

15:40 <konradybcio> why does the patch need a yes/no right now?

15:40 <konradybcio> i can rubber stamp all the patches that come through my inbox, but the quality of the kernel would greatly degrade..

15:40 <krzk> because it will or will not be applied

15:40 <konradybcio> well there is clearly need for more insight

15:41 <konradybcio> i.e. "does this patch even make sense from a hw representation perspective"

15:41 <krzk> Nothing like that was expressed in that thread. Rob asked for changes and you responded questioning it.

15:41 <krzk> So "more insight" is not even considered part of that arguments/discussion. Looks like unrelated issue to be fixed.

15:45 <int-hellhound> ungeskriptet: i really doubt that 8650 driver can be used in 8635, just looking by the amount of pins in the driver. so, we took one from android kernel sources and adapted to the mainline.

15:59 <flamingradian[m]> oh 670 has its own tlmm/pinctrl driver, it just uses 845 clocks

16:02 <int-hellhound> yeah?

16:03 <int-hellhound> thats interesting

16:03 <int-hellhound> but its not my case, sadly :D

16:37 <vknecht[m]> int-hellhound: maybe related ? https://patchwork.kernel.org/project/linux-arm-msm/patch/20250611143911.48501-1-brgl@bgdev.pl/

16:51 <int-hellhound> Nah, i don't think so

18:28 <int-hellhound> i got timed out i guess

18:29 <int-hellhound> dunno if my message got send. tried the patch that was sent. didnt helped