ikarso has quit [Quit: Connection closed for inactivity]
dsimic has quit [Ping timeout: 264 seconds]
dsimic has joined #u-boot
prabhakarlad has joined #u-boot
prabhakar has joined #u-boot
rockosov has quit [Quit: WeeChat 3.4-dev]
rockosov has joined #u-boot
rockosov has quit [Client Quit]
rockosov has joined #u-boot
rockosov has quit [Quit: WeeChat 3.4-dev]
rockosov has joined #u-boot
mmu_man has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
ikarso has joined #u-boot
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #u-boot
prabhakar48 has joined #u-boot
prabhakarlad has joined #u-boot
prabhakar has quit [Ping timeout: 264 seconds]
prabhakar48 has quit [Ping timeout: 260 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
glaroque has joined #u-boot
prabhakar has joined #u-boot
prabhakarlad has joined #u-boot
mmu_man has quit [Quit: Lost terminal]
<Tartarus>
xypron: I'm going to make an attempt at what I just mentioned, re gcc/clang.rst
<calebccff>
Clamor: where does priv come from in palmas gpio?
<calebccff>
Clamor: the max77663 one is just doing pmic_read(dev->parent, ...);
<calebccff>
what am I meant to be looking for here?
<calebccff>
to be clear, the qcom pmic gpio driver is both a GPIO and a pinctrl driver, because upstream DT specifies pinctrl nodes...
<Clamor>
calebccff: what is your goal
<Clamor>
Bind gpio driver as pmic's child?
<Tartarus>
And sigh, the first set of issues is that our clang docs are kinda out of date in general
<Tartarus>
And, further sigh, is there some easy way in python to pass say --clang-X and go "Ah, I was told clang-X, let me know that", without having to case each possible value of X?
<Tartarus>
Today buildman can't really do clang for anything other than sandbox since we still need to know what CROSS_COMPILE is, we just instead set CC/HOSTCC, so I was thinking we could just pass --clang-X and work from that
<calebccff>
i think it's mostly ok, the biggest hack is having plat data allocated for the NOP device and doing dev_set_plat() for each child device
<Clamor>
calebccff: interesting solution
<Clamor>
Do you need both of them active?
<calebccff>
we have similar things for the qualcomm clock/reset drivers and the SoC GPIO/pinctrl drivers
<calebccff>
yeah
<Clamor>
Tegra has combined car as well
<calebccff>
would it make sense to eventually look to switch to the Linux model where multiple drivers can be associated with a single device?
Schimsalabim___ has quit [Quit: Schimsalabim___]
<calebccff>
Or alternatively can we integrate this NOP model more tightly somehow (and maybe hide it)
<Clamor>
Actually you can bind plain driver and reuse binding
<calebccff>
Clamor: "plain driver"?
<Clamor>
Driver which is not associated with device tree node directly
<calebccff>
i think technically that's what I have here, i mean i associate the node but i don't actually reference it, all the DT stuff is handled from the NOP driver
<Clamor>
Like pmic does, I understand
<calebccff>
Clamor: see also drivers/clk/qcom/clock-qcom.c qcom_cc_bind()
<calebccff>
each SoC implements its own driver with this common bind function which binds the "real" clock driver and the reset driver
<calebccff>
this time the only shared state is static const at build time
<calebccff>
so it's a bit easier, we don't have to enforce probe ordering
<Clamor>
Create a gpio driver and bind pincontrol from it
<Tartarus>
And oh right, we can't use clang really anymore to build thanks to 2027e99e61aa ("Makefile: Run defconfig files through the C preprocessor") and https://github.com/llvm/llvm-project/issues/78778
<calebccff>
Clamor: I remember that having issues... But yeah i guess it can work
<calebccff>
oh right i did try this before but i bound the pinctrl device as a child of the pmic rather than of the gpio device, so that made sharing data harder
<Clamor>
calebccff: binding to pmic can work as well
<Clamor>
Even without nodes
<Clamor>
But it is a bit more complex
<calebccff>
Clamor: not if I want to allocate data and share it between the devices
<Clamor>
Well, you can share pmic's device ;) wonky but these abstractions are physically the same device
<calebccff>
if i allocate data for the gpio device and pass it to the pinctrl device without enforcing that the gpio device outlives the pinctrl device than we risk UAFs
<Clamor>
Too many variables, hard to tell directly would driving in
<Clamor>
Sorry
<calebccff>
no worries, i think i overcomplicated a bit, and probably i can just make the gpio a child of the pinctrl
<Clamor>
Gpio framework will not be happy :)
<calebccff>
urgh i can do it the other way around? XD
<Clamor>
Not sure about pincontrol. This is why I suggested to bind pincontrol to gpio
<Clamor>
If pmic had nodes per device it would be much simpler
<calebccff>
pmic framework should climb the device heirarchy
<calebccff>
but anyways that's only half the issue, i want to do expensive DT parsing once and then pass the data to both device that need it (like pin count)
<Clamor>
Do it in pmic and share via platdata
<Clamor>
Assume you are doing this already
<calebccff>
the pmic device should not care about the number of GPIOs one of its subdevices has(?)
<calebccff>
not all PMICs have GPIO functions, etc..
<Clamor>
Yes
<Clamor>
Pmic gpio cell is optional
<Clamor>
Same as regulators
persmule has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
<calebccff>
Clamor: the GPIO device is a subnode of the PMIC, not sure if i understand you correctly here...
monstr has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
hsv has quit [Quit: leaving]
hsv has joined #u-boot
Leopold_ is now known as Leopold
Clamor has quit [Ping timeout: 264 seconds]
Clamor has joined #u-boot
<xypron>
Tartarus: Using includes may make maintenance easier. But the raw text is not readable anymore.
<xypron>
It might be preferable to use references instead.
<Tartarus>
And the rendering is copy/paste
<Tartarus>
able which is part of the requirements TI was looking at with the pages
Clamor has quit [Read error: Connection reset by peer]
<Tartarus>
But yeah, I'm not 100% sure how things should look in the end
<Tartarus>
since there's no real macro/template mechanism
ikarso has quit [Quit: Connection closed for inactivity]
ikarso has joined #u-boot
slobodan has joined #u-boot
GNUtoo has quit [Ping timeout: 255 seconds]
GNUtoo has joined #u-boot
Guest4494 has quit [Quit: Client closed]
mmu_man has joined #u-boot
slobodan has quit [Ping timeout: 272 seconds]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
ezulian_ has quit [Ping timeout: 255 seconds]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
<xypron>
Tartarus: the build instructions should work for users withe minimal experience. This is why our current text says " If you are on s Debian based distro use this CROSS_COMPILE value." After updating the documentation, we should have something similar easy to follow.
<Tartarus>
I agree it should be easy to follow since I want to point as much of the board docs, which I think are more frequently referenced and are less consistent, to them