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
dliviu has quit [Quit: Going away]
dliviu has joined #armlinux
TheCoffeMaker has joined #armlinux
TheCoffeMaker has quit [Remote host closed the connection]
TheCoffeMaker has joined #armlinux
TheCoffeMaker has quit [Client Quit]
TheCoffeMaker has joined #armlinux
apritzel_ has quit [Ping timeout: 246 seconds]
jclsn has quit [Ping timeout: 250 seconds]
jclsn has joined #armlinux
Nact has joined #armlinux
cbeznea has joined #armlinux
amitk has joined #armlinux
chipxxx has joined #armlinux
Nact has quit [Quit: Konversation terminated!]
guillaume_g has joined #armlinux
chipxxx has quit [Quit: Leaving]
<ukleinek>
krzk: you can use a static inline func to init a struct?
<arnd>
no, there you can only put constant expressions into a static initialization. IIRC there are cases where one would intuitively think of an expression of constant but the C standard does not, so those are not allowed either
<arnd>
for the specific case of of_match_ptr() and others like it, the problem is actually something else: you can't easily have a declaration for an object in there, which prevents you from defining it as
<arnd>
this construct would in fact let the compiler silently drop any references to the match table and anything referenced from its ->data fields, but it requires having either a defintion or a declaration for the object pointed to
<arnd>
if the table is in an #ifdef, you just get an error about a missing declaration
<krzk>
indeed, so no static inline
<krzk>
there is still other task - enabling of_match_ptr() also for ACPI
amitk_ has joined #armlinux
<geertu>
ukleinek: krzk: Yes, W=1 is the missing piece. I (and probably lots of other people) had to spend some time to discover that...
<geertu>
arnd: I'd love to use PTR_IF(IS_ENABLED(CONFIG_OF), (_ptr)), cfr. pm_ptr()
<geertu>
But that does require dropping all the existing #ifdefs (and the __maybe_unused, although that is not really required) around all table definitions
<geertu>
In the long run, it's probably worth doing that, though.
<geertu>
And the longer we wait, the more work ;-)
<arnd>
I think the only sensible way forward is to just remove them all. We introduced of_match_ptr() at a time when CONFIG_OF was just an experiment and users were worried about bloat it causes
<arnd>
Now there are very few drivers left that support it optionally but are also still used with static platform_device definitions, so there really isn't much to save here.
<geertu>
That's true, CONFIG_PM is more the norm now.
<geertu>
CONFIG_OF I meant (my mind was thinking about CONFIG_PM in parallel, and pm_ptr() still makes sense IMHO)
<arnd>
I also suspect that a lot of drivers using pm_ptr() are just broken and don't work correctly when you disable CONFIG_PM, but that is a completely separate matter
<geertu>
(although the latter is mostly while wearing my m68k hat, as even the SRAM-only RZ/A selects CONFIG_PM)
<javierm>
arnd: agreed about just removing all. That's what I meant when I said that wondered how much value it adds
Norkle has quit [Ping timeout: 268 seconds]
Norkle has joined #armlinux
<javierm>
because for me the combination of of_match_ptr() and ifdef guards in the of_device_id table definition is a constant source of churn
<arnd>
krzk: herbert has an Imagination crypto accelerator on his x86 laptop? ;-)
<javierm>
krzk: "for every single driver", is only for drivers that support both ACPI and OF in practice
<javierm>
if a driver is OF-only or ACPI-only, then probably Kconfig is the correct way to add that dependency to prevent it for building it
frieder has joined #armlinux
<javierm>
krzk: in practice most users will use a distro and there you need to have all the device ID tables anyways since a distro can't assume that firmware interface would be used
<javierm>
for general purposes distros I mean
<arnd>
I'd argue that anyone using ACPI does not care about wasting 100 bytes of .data because they have gigabytes of RAM
<javierm>
arnd: that too :)
<krzk>
You forgot the PRP0001, so ACPI folks might actually want OF table ID even without CONFIG_OF
<krzk>
The entire point is to have OF-only driver available for ACPI
<krzk>
(although not the case for imgtec driver, obviously)
headless has joined #armlinux
<javierm>
krzk: right, another argument for just having it unconditionally
iivanov has joined #armlinux
<ardb>
krzk: agreed
<ardb>
krzk: case in point, my synquacer box uses PRP0001 for binding to atmel,atsha204a, atmel,atecc508a and gpio-leds
<ardb>
of course, you cannot actually disable OF on arm64
cbeznea has quit [Quit: Leaving.]
prabhakarlad has joined #armlinux
viorel_suman has joined #armlinux
apritzel has joined #armlinux
biju has joined #armlinux
sszy has joined #armlinux
<biju>
Hi all, Just a question from boot log, 2 sched_clocks registered on my system and system selects [2] instead of [1] as sched_clock is based on rate. is it expected behaviour eventhoug [1] has more wrap time than [2]?
<biju>
[1] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
<biju>
[2] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 21474836475ns
<arnd>
I guess 21s is plenty for sched_clock() wraparound
<ukleinek>
I think a wrap around of 21s implies an additional irq every 11.5 s, that's okish
luispm has quit [Quit: Leaving]
<biju>
Thanks arnd and ukleinek.
chipxxx has joined #armlinux
marc|gonzalez has joined #armlinux
<marc|gonzalez>
Heyo :)
Grimler has joined #armlinux
milkylainen has quit [Read error: Connection reset by peer]
patersonc[m] has joined #armlinux
luispm has joined #armlinux
cbeznea has joined #armlinux
tlwoerner has quit [Read error: Connection reset by peer]
headless has quit [Quit: Konversation terminated!]
balrog has quit [Quit: Bye]
balrog has joined #armlinux
cleger has quit [Quit: Leaving]
chipxxx has quit [Ping timeout: 248 seconds]
<marc|gonzalez>
broonie: I don't understand reg vs ranges... I have a "simple-bus" node with reg = <0x0 0x38000 0x0 0x400>; and ranges = <0x0 0x0 0x0 0x38000 0x0 0x400>;
<marc|gonzalez>
I'm trying to figure the meaning out
<marc|gonzalez>
I mean, if it's a simple-bus, can't we assume identity as translation?
<broonie>
marc|gonzalez: I'm not a DT expert... krzk robher ^^^ ?
<marc|gonzalez>
broonie: my mind played me a nasty trick and I mis-remembered you as the DT maintainer, sorry :)
<robher>
marc|gonzalez: 'ranges' is how you translate from parent address space to child address space. 'reg' is just space with registers.
<robher>
A simple-bus doesn't have registers because it is simple.
<marc|gonzalez>
robher: for a simple-bus without a compatible string, the reg prop is useless, correct?
<bjdooks>
does the dtc have support for != 32bit integers?
<marc|gonzalez>
bjdooks: I thought every 64-bit number/address had to be spelled out as 2 32-bit parts
<robher>
More DT questions! If only there was a DT IRC channel...
<robher>
bjdooks: yes, /bits/ 8|16|32|64
<robher>
bjdooks: But in the end in DTBs, it's all just byte strings.
<marc|gonzalez>
robher: do you prefer I move to the DT channel?
<bjdooks>
for ranges i ended up making qemu output the bits i wanted once i got the setup for my pcie right
<robher>
marc|gonzalez: no point mid conversation.
<robher>
marc|gonzalez: 'reg' is not allowed in that case. You need a compatible to know what is in 'reg'.
<marc|gonzalez>
robher: noted DT channel for future
<marc|gonzalez>
robher: may I CC you on a DTS patch that removes reg then?
<robher>
marc|gonzalez: If there's registers in the h/w, why would you hide them?
<robher>
sounds like you need a specific compatible instead.
<marc|gonzalez>
robher: in the doc there's a block called DRAM Memory Controller, which lumps together various regs for similar "stuff" handled by different drivers
<marc|gonzalez>
What they decided to do was declare dmc as a simple bus with child nodes for the various "stuffs"
<rockosov>
krzk: robher Hello! Hope I'm tagging right guys :) Rob, Krzysztof, maybe it's easier to discuss dt bindings license here in chat.
<krzk>
rockosov: you got quite clear response from robher that the change is not really correct. Now whether akpm wants a follow up or not, it is not the question to me.
<krzk>
I would assume that he will drop the patch
iivanov has quit [Remote host closed the connection]
torez has joined #armlinux
torez has quit [Remote host closed the connection]
torez has joined #armlinux
<rockosov>
krzk: Thank you for clarification. Then I'll rework the patch to new patterns suggested by Rob. Now it's clear.
Grimler has quit [Quit: Lost terminal]
headless has quit [Quit: Konversation terminated!]
<marc|gonzalez>
Did they raise the value of core.abbrev to 14 at some point?
<marc|gonzalez>
same player shoot again
<marc|gonzalez>
In git, did they raise the default value of core.abbrev to 14 around 2020?
<marc|gonzalez>
No, it's not git because I only get 10 in a different repo... /me confused
<javierm>
marc|gonzalez: do you have a set as a per repo config (.git/config) ?
<javierm>
I still have 12 in my global git config
Amit_T has joined #armlinux
<marc|gonzalez>
javierm: I did a git config -l | grep abbrev : empty :/
viorel_suman has quit [Quit: WeeChat 3.6]
<marc|gonzalez>
So it seems to be some kind of project default that's not show by git config
<marex>
marc|gonzalez: if you have bajilion of commits in repo, the abbrev commit hash might be > 12 chars
<marc|gonzalez>
marex: Well, do have linux + linux-before + linux-history all stitched up
<marc|gonzalez>
but does that mean there exist at least one conflict between two 13-char hashes?
<marex>
marc|gonzalez: I cannot tell, its just my observation that at some point, git show --pretty='tformat:%h' started generating 13 char abbrevs
<marc|gonzalez>
marex: OK, checkpatch complains that my Fixes tag are 14 chars long :)
<marex>
marc|gonzalez: yeah, I know
<marex>
marc|gonzalez: it would be interesting to know what's up here, maybe ask the git maintainers instead ?
<marc|gonzalez>
I chopped the hash until git said there was an ambiguity, it was like 7 chars
<marex>
marc|gonzalez: maybe the conflict is with a tree hash or other such non-commit hash ?
<marc|gonzalez>
My uneducated guess is that git has somehow a notion of every prefix collision (meh not so likely) and sets abbrev to N+1
<marc|gonzalez>
I suppose I can force abbrev down to 12 in the project config :)
<marc|gonzalez>
ah that makes much more sense! thanks _jannau_
<marc|gonzalez>
Because I stitched 3 repos together, I must have a boat load of objects
iivanov has joined #armlinux
marc|gonzalez has quit [Quit: Leaving.]
headless has joined #armlinux
torez has joined #armlinux
apritzel has quit [Ping timeout: 265 seconds]
torez has quit [Quit: torez]
torez has joined #armlinux
torez has quit [Client Quit]
Grimler has joined #armlinux
luispm has quit [Quit: Leaving]
<CounterPillow>
I'm writing a driver for a hardware block that is behind an IOMMU, and only handles 32-bit addresses. It's connected to the AXI bus. Do I set dma_set_coherent_mask or dma_set_mask to make it deal with that? Does the question I'm asking even make sense?
prabhakarlad has joined #armlinux
tom5760 has quit [Read error: Connection reset by peer]
tom5760 has joined #armlinux
cbeznea has joined #armlinux
hanetzer has quit [Ping timeout: 240 seconds]
Amit_T has quit [Quit: Leaving]
amitk has quit [Ping timeout: 255 seconds]
hanetzer has joined #armlinux
iivanov_ has joined #armlinux
apritzel_ has joined #armlinux
iivanov__ has joined #armlinux
iivanov has quit [Ping timeout: 255 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
iivanov_ has quit [Ping timeout: 240 seconds]
iivanov has joined #armlinux
iivanov__ has quit [Ping timeout: 240 seconds]
prabhakarlad has quit [Quit: Client closed]
iivanov_ has joined #armlinux
iivanov has quit [Ping timeout: 260 seconds]
prabhakarlad has joined #armlinux
frieder has quit [Remote host closed the connection]
headless has quit [Quit: Konversation terminated!]
biju has quit [Quit: Konversation terminated!]
cbeznea has quit [Ping timeout: 276 seconds]
iivanov_ has quit [Ping timeout: 255 seconds]
prabhakarlad has quit [Quit: Client closed]
Emantor has quit [Ping timeout: 265 seconds]
Fridtjof_ has joined #armlinux
Fridtjof has quit [Ping timeout: 265 seconds]
Emantor has joined #armlinux
macromorgan has quit [Read error: Connection reset by peer]