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
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #armlinux
Pali has quit [Ping timeout: 252 seconds]
scosu[m] has quit [Ping timeout: 240 seconds]
scosu[m] has joined #armlinux
apritzel has quit [Ping timeout: 256 seconds]
Misotauros has quit [Ping timeout: 268 seconds]
amitk has joined #armlinux
Lucanis has joined #armlinux
saiprakash has joined #armlinux
saiprakash has quit [Ping timeout: 256 seconds]
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #armlinux
guillaume_g has joined #armlinux
apritzel has joined #armlinux
cleger has joined #armlinux
apritzel has quit [Ping timeout: 256 seconds]
frieder has joined #armlinux
headless has joined #armlinux
iivanov has quit [Quit: Leaving...]
iivanov has joined #armlinux
iivanov has quit [Client Quit]
iivanov has joined #armlinux
djrscally has joined #armlinux
nsaenz has joined #armlinux
saiprakash has joined #armlinux
luispm has joined #armlinux
sszy has joined #armlinux
prabhakarlad has joined #armlinux
tre has joined #armlinux
matthias_bgg has joined #armlinux
headless has quit [Read error: Connection reset by peer]
prabhakarlad has quit [Quit: Client closed]
alexels has joined #armlinux
mcoquelin has quit [Remote host closed the connection]
monstr has joined #armlinux
mcoquelin has joined #armlinux
mcoquelin has quit [Ping timeout: 252 seconds]
mcoquelin has joined #armlinux
saiprakash has quit [Quit: Client closed]
apritzel has joined #armlinux
shenki has joined #armlinux
archetech has joined #armlinux
cbeznea has joined #armlinux
<javierm>
geertu: thanks for fixing my bugs! and sorry for the incovenience
pg12 has quit [Remote host closed the connection]
pg12 has joined #armlinux
prabhakarlad has joined #armlinux
<geertu>
javierm: You're welcome. I'm happy to get it sorted out, finally.
<geertu>
arnd: Looks like we already have several "depends on SOC_SP7021"...
<arnd>
yes, they have merged some drivers already, the main soc support is just blocked on the clk driver at the moment, and they are struggling a lot with the driver for their 8051 support processor
<arnd>
I wonder if some of the drivers are related to the ones we had for arch/score/ originally
<geertu>
I guess most of these should depend on ARCH_SUNPLUS instead?
<arnd>
geertu: probably, but I'm not too worried about that, this the only chip from sunplus that I've ever seen mentioned anywhere.
<arnd>
their older chips were based on either score or nds32
<arnd>
if they make any new chips to run Linux in the future, it seems more likely that those will be Andes RISC-V based...
matthias_bgg has quit [Ping timeout: 252 seconds]
torez has joined #armlinux
<marex>
sboyd: hey, can you give that rs9 clock driver one more look ? I guess there is no way it lands in 5.18 anymore though ?
<marex>
sboyd: also, what can we do about those critical-clocks ?
matthias_bgg has joined #armlinux
tre has quit [Ping timeout: 252 seconds]
tre has joined #armlinux
monstr has quit [Remote host closed the connection]
mriesch has joined #armlinux
<mriesch>
hi all
<mriesch>
not sure whether this is the right place to ask this, but how can a load switch be represented in the device tree?
<mriesch>
i think for models that try again automatically after e.g. a overcurrent event fixed-regulator can be used. but what about models that need toggling the enable pin after a fault has occured?
tre has quit [Remote host closed the connection]
headless has joined #armlinux
Pali has joined #armlinux
Misotauros has joined #armlinux
nullheroes has quit [Ping timeout: 272 seconds]
nullheroes has joined #armlinux
alexels has quit [Quit: WeeChat 3.4]
luispm has quit [Quit: Leaving]
frieder has quit [Remote host closed the connection]
nsaenz has quit [Remote host closed the connection]
archetech has quit [Quit: Konversation terminated!]
prabhakarlad has quit [Quit: Client closed]
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 252 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
Nact has joined #armlinux
apritzel has joined #armlinux
iivanov has quit [Quit: Leaving...]
headless has quit [Quit: Konversation terminated!]
<mriesch>
broonie: ^^^ ?
Misotauros has quit [Ping timeout: 256 seconds]
<broonie>
mriesch: if the device handles faults by disabling and reenabling it should just do that? But normally faults are fairly catastrophic - the handling is more about preventing damage.
<mriesch>
broonie: the typical application is e.g. providing the vbus voltage for usb host ports.
<mriesch>
there are some load switches that try again after some time, and some need to be re-enabled by software
<broonie>
Then do the disable/renable. I’m just explaining why there’s very little handling of this upstream
<mriesch>
i guess my question is whether there is already a driver for that
<broonie>
No, and it’s the consumer that needs to do that not the regulator.
<broonie>
The regulator will just flag the error, any handling is up to the consumer.
<mriesch>
ah ok
<mriesch>
but is there a mechanism already to read out a certain gpio that is connected to the fault pin of the load switch?
<mriesch>
mechanism in fixed-regulator or similar
<broonie>
No, you’d want to write a driver for the regulator.
<mriesch>
ok, i'll give it a shot
<mriesch>
i would guess the consumer is passed a certain notification in the event of overcurrent?
<broonie>
Yes, there’s a set of notifications defined - there’s a bunch of existing drivers doing the notification side
<mriesch>
great, i'll have a look. thanks for the input, broonie
<broonie>
Np
cbeznea has quit [Ping timeout: 252 seconds]
amitk has quit [Ping timeout: 256 seconds]
djrscally has quit [Quit: Konversation terminated!]