ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
shoragan has quit [Read error: Connection reset by peer]
a3f has quit [Read error: Connection reset by peer]
a3f has joined #armlinux
shoragan has joined #armlinux
apritzel has quit [Ping timeout: 272 seconds]
mag has quit [Quit: Leaving]
hanetzer has quit [Ping timeout: 245 seconds]
hanetzer has joined #armlinux
jclsn has quit [Ping timeout: 245 seconds]
jclsn has joined #armlinux
mwalle_ has quit [Quit: WeeChat 3.0]
sakman has joined #armlinux
mwalle has joined #armlinux
rvalue has quit [Ping timeout: 246 seconds]
monstr has joined #armlinux
amitk has joined #armlinux
rvalue has joined #armlinux
apritzel has joined #armlinux
iivanov has joined #armlinux
apritzel has quit [Ping timeout: 272 seconds]
biju has joined #armlinux
luispm has joined #armlinux
<biju>
I ma sseing build error with today's next
<biju>
make[2]: *** No rule to make target '/tftpboot/RZ-V2L/lib/modules/6.5.0-rc1-next-20230717-g015ed6c30619/kernel/drivers/phy/rockchip/phy-rockchip-naneng-combphy.ko', needed by '__modinst'. Stop.
<biju>
vmlinux.a: member drivers/net/ethernet/freescale/dpaa/dpaa_eth.o in archive is not an object
frieder_ has joined #armlinux
Lucanis has joined #armlinux
Lucanis0 has quit [Ping timeout: 246 seconds]
Lucanis0 has joined #armlinux
Lucanis0 has joined #armlinux
Lucanis0 has quit [Changing host]
Lucanis has quit [Ping timeout: 246 seconds]
<biju>
please ignore me. make clean, fixed the build error.
sszy has joined #armlinux
rvalue has quit [Ping timeout: 246 seconds]
rockosov has joined #armlinux
rvalue has joined #armlinux
luispm has quit [Quit: Leaving]
headless has joined #armlinux
Turingtoast has joined #armlinux
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 272 seconds]
luispm has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
ajb-lina- has joined #armlinux
vireshk- has joined #armlinux
vkoul- has joined #armlinux
rvalue has quit [Ping timeout: 245 seconds]
rvalue has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
jpanisbl has joined #armlinux
<javierm>
geertu: the v2 patch shared is on top of your series, I forgot to mention that. It's untested though :)
<javierm>
geertu: if you agree with the approach and fixes the oops, feel free to include in your v2 series
amitk_ has joined #armlinux
headless has quit [Quit: Konversation terminated!]
amitk_ has quit [Ping timeout: 272 seconds]
rockosov has quit [Quit: WeeChat 3.4-dev]
frieder_ has quit [Ping timeout: 245 seconds]
jpanisbl has quit [Quit: Konversation terminated!]
frieder_ has joined #armlinux
frieder_ has quit [Ping timeout: 272 seconds]
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
amitk_ has joined #armlinux
amitk_ has quit [Ping timeout: 260 seconds]
frieder_ has joined #armlinux
<javierm>
geertu: also, it seems my assumption that device and drm_device lifetimes don't play nice together was correct, because even when my v2 works it crashes on poweroff
<javierm>
i2c_device_shutdown() -> ssd130x_i2c_shutdown() -> ssd130x_shutdown() which finally leads to an atomic commit and the primary plane update callback being called even after a .remove
<ukleinek>
javierm: but in that case the device is still bound
<javierm>
ukleinek: then I'm confused. But this was after trying to allocate a buffer as a device managed resource
<javierm>
I've found an alternative fix though that I believe is more correct so I didn't dig that deeper on that
<ukleinek>
javierm: i2c_device_shutdown() has: if (!dev->driver) return;
<javierm>
ukleinek: yeah, just looked at that. I don't know then
<ukleinek>
javierm: if you shutdown before .probe() returns, dev->driver might still be the driver that is supposed to bind.
<javierm>
ukleinek: yeah, this was way after the probe finished and the driver was registered. But as said, I dropped that patch anyways for different reasons so wasn't worth to continue digging on the issue
<ukleinek>
javierm: luckily this wasn't much wasted time (compared to other topics ...)
<javierm>
ukleinek: yeah...
* ukleinek
wonders if that shutdown while probe still runs is a real issue and asks gregkh (in #kernelnewbies)