Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2024.01 is OUT / Merge Window is OPEN, next branch is CLOSED / Release v2024.04 is scheduled for 02 April 2024 / Channel archives at https://libera.irclog.whitequark.org/u-boot
hsv has quit [Ping timeout: 240 seconds]
hsv has joined #u-boot
vagrantc has quit [Ping timeout: 260 seconds]
vagrantc has joined #u-boot
vagrantc has quit [Quit: leaving]
F0rTex has quit [Ping timeout: 264 seconds]
F0rTex has joined #u-boot
jclsn has quit [Ping timeout: 255 seconds]
jclsn has joined #u-boot
mmu_man has quit [Ping timeout: 264 seconds]
srk_ has joined #u-boot
srk| has joined #u-boot
srk has quit [Ping timeout: 255 seconds]
srk_ has quit [Ping timeout: 252 seconds]
srk| is now known as srk
srk_ has joined #u-boot
srk has quit [Ping timeout: 264 seconds]
srk_ is now known as srk
srk_ has joined #u-boot
srk has quit [Ping timeout: 255 seconds]
srk_ is now known as srk
persmule has quit [Remote host closed the connection]
zsoltiv_ has quit [Ping timeout: 255 seconds]
Clamor has joined #u-boot
stefanro has quit [Ping timeout: 256 seconds]
stefanro has joined #u-boot
edwinistrator25 has joined #u-boot
edwinistrator2 has quit [Ping timeout: 255 seconds]
edwinistrator25 is now known as edwinistrator2
monstr has joined #u-boot
Stat_headcrabed has joined #u-boot
niska has quit [Quit: Leaving]
niska has joined #u-boot
linfax has joined #u-boot
ezulian_ has joined #u-boot
goliath has joined #u-boot
frieder has joined #u-boot
mckoan|away is now known as mckoan
davlefou has quit [Ping timeout: 255 seconds]
davlefou has joined #u-boot
prabhakar has joined #u-boot
prabhakarlad has joined #u-boot
haritzondo is now known as haritz
haritz has joined #u-boot
haritz has quit [Changing host]
matthias_bgg has joined #u-boot
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #u-boot
ikarso has joined #u-boot
ezulian_ has quit [Quit: ezulian_]
ezulian has joined #u-boot
jmasson has joined #u-boot
sszy has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
prabhakar has quit [Ping timeout: 260 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
prabhakar has joined #u-boot
prabhakarlad has joined #u-boot
monstr has quit [Ping timeout: 252 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
prabhakar has quit [Ping timeout: 255 seconds]
<Clamor> calebccff: check palmas gpio driver
<Clamor> Or max77663 gpio and pmic drivers
monstr has joined #u-boot
sigmaris has quit [Quit: ZNC - https://znc.in]
sigmaris has joined #u-boot
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> Clamor: I need a pinctrl driver and a GPIO driver bound to the same DT node, and ideally without duplicating shared data. This is what I've come up with: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/044bf68361793d0472d402cffe92b4c76b15afd7
prabhakar has quit [Ping timeout: 255 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
<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
<Clamor> And then request data from pmic
prabhakarlad has joined #u-boot
prabhakar has joined #u-boot
<calebccff> Clamor: i can't do what you're suggesting without having to duplicate the data initialised here https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/blob/044bf68361793d0472d402cffe92b4c76b15afd7/drivers/gpio/qcom_pmic_gpio.c#L359
<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
<calebccff> this is my last attempt... see qcom_pmic_pinctrl_bind() https://lore.kernel.org/u-boot/20240130-b4-qcom-common-target-v3-12-e523cbf9e556@linaro.org/
<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...
<Clamor> This clarifies the issue
<Clamor> Where is pincontrol configured?
<Clamor> Under state? Are they changed further?
<calebccff> well, i specifically just care about the db410c board for USB role switching https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/apq8016-sbc.dts#n657
<Clamor> It is one time action?
<Clamor> Or you have to dynamically reconfigure
<calebccff> dynamically reconfigure
<calebccff> I want to minimise DT changes in U-Boot and keep a close eye on every non-standard DT thing we do
<Clamor> Sure
<Clamor> You are reconfiguring only from board?
<calebccff> just that function, i don't think any drivers switch pinctrl states
<Clamor> I would try to bound pincontrol to gpio driver directly
jmasson has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<calebccff> Clamor: so have the pinctrl device be a child of the gpio device?
<calebccff> i think that's the best option
<Clamor> Yeah, seems so
ezulian_ has joined #u-boot
ezulian has quit [Ping timeout: 272 seconds]
ikarso has joined #u-boot
Schimsalabim has joined #u-boot
stefanro has quit [Quit: Leaving.]
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
mckoan is now known as mckoan|away
vagrantc has joined #u-boot
goliath has joined #u-boot
ldevulder has quit [Ping timeout: 246 seconds]
linfax has quit [Ping timeout: 264 seconds]
ldevulder has joined #u-boot
Kwiboo- is now known as Kwiboo
matthias_bgg has quit [Quit: Leaving]
Guest4494 has joined #u-boot
Guest4494 has quit [Quit: Client closed]
Guest4494 has joined #u-boot
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