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
geertu has quit [*.net *.split]
mripard_ has quit [*.net *.split]
Xogium has quit [*.net *.split]
Lucanis has quit [*.net *.split]
macromorgan has quit [*.net *.split]
vup has quit [*.net *.split]
rfried has quit [*.net *.split]
mcoquelin has quit [*.net *.split]
mal`` has quit [*.net *.split]
[florian] has quit [*.net *.split]
ziofork52 has quit [*.net *.split]
shoragan has quit [*.net *.split]
[florian] has joined #armlinux
Lucanis has joined #armlinux
geertu has joined #armlinux
vup has joined #armlinux
Lucanis has quit [Changing host]
Lucanis has joined #armlinux
mcoquelin has joined #armlinux
shoragan has joined #armlinux
shoragan has quit [Changing host]
shoragan has joined #armlinux
Xogium has joined #armlinux
rfried has joined #armlinux
mal`` has joined #armlinux
mripard_ has joined #armlinux
Lucanis has quit [Quit: Leaving]
Lucanis has joined #armlinux
Grimler has quit [Ping timeout: 260 seconds]
geertu has quit [Ping timeout: 248 seconds]
geertu has joined #armlinux
alpernebbi has quit [Ping timeout: 250 seconds]
jlinton has joined #armlinux
alpernebbi has joined #armlinux
amitk has joined #armlinux
_whitelogger has joined #armlinux
amstan has joined #armlinux
kos_tom has quit [*.net *.split]
a3f has quit [*.net *.split]
mriesch has quit [*.net *.split]
netonaut_ has quit [*.net *.split]
olofj has quit [*.net *.split]
maennich has quit [*.net *.split]
robclark has quit [*.net *.split]
robher has quit [*.net *.split]
pjw has quit [*.net *.split]
ccaione has quit [*.net *.split]
scosu[m] has quit [*.net *.split]
agraf has quit [*.net *.split]
sjg1 has quit [*.net *.split]
khilman has quit [*.net *.split]
mrlemke has quit [*.net *.split]
marex has quit [*.net *.split]
kristinam has quit [*.net *.split]
iwamatsu has quit [*.net *.split]
kristinam has joined #armlinux
kos_tom has joined #armlinux
mriesch has joined #armlinux
mrlemke has joined #armlinux
iwamatsu has joined #armlinux
robclark has joined #armlinux
olofj has joined #armlinux
khilman has joined #armlinux
pjw has joined #armlinux
robher has joined #armlinux
ccaione has joined #armlinux
netonaut_ has joined #armlinux
sjg1 has joined #armlinux
maennich has joined #armlinux
agraf has joined #armlinux
scosu[m] has joined #armlinux
marex has joined #armlinux
a3f has joined #armlinux
guillaume_g has joined #armlinux
SallyAhaj has quit [Ping timeout: 246 seconds]
cbeznea has joined #armlinux
Misotauros has quit [Ping timeout: 256 seconds]
jlinton has quit [Quit: Client closed]
iivanov has joined #armlinux
Pali has joined #armlinux
frieder has joined #armlinux
frieder_ has joined #armlinux
frieder has quit [Read error: Connection reset by peer]
Pali has quit [Ping timeout: 246 seconds]
headless has joined #armlinux
mcoquelin has quit [Remote host closed the connection]
* ukleinek
grumbles about fs/reiserfs/namei.c:1646:1: error: the frame size of 1176 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
<ukleinek>
bah, there are more
<ukleinek>
lib/crypto/curve25519-fiat32.c:864:1: error: the frame size of 1280 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
<ukleinek>
(v5.18-rc1, gnueabihf toolchain based on gcc10 as provided by Debian)
<tmlind>
ukleinek: see also that 8250 regression i emailed about on friday :)
<ukleinek>
tmlind: link? Didn't find it in my mailbox (subject:8250 date:2022-04-08..)
<ukleinek>
tmlind: FTR: Didn't find it because it's from Thursday :-)
<tmlind>
ukleinek: ah ok sorry :)
<ukleinek>
tmlind: ah, this is independant from my grumble about frame sizes
<tmlind>
yup
<ukleinek>
tmlind: you wanna increase your patch count? :-)
<tmlind>
ukleinek: sure, at least i can test it :)
<tmlind>
will send a bit later on
<ukleinek>
tmlind: đź‘Ť
<ukleinek>
tmlind: FTR: I'm sure your concern is right and needs a fix
<tmlind>
ukleinek: ok
matthias_bgg has joined #armlinux
monstr has joined #armlinux
nsaenz has joined #armlinux
headless has quit [Ping timeout: 240 seconds]
headless has joined #armlinux
frieder_ has quit [Ping timeout: 240 seconds]
frieder_ has joined #armlinux
frieder_ has quit [Ping timeout: 250 seconds]
cleger has joined #armlinux
mripard_ has quit [Ping timeout: 256 seconds]
frieder_ has joined #armlinux
Turingtoast has joined #armlinux
frieder_ has quit [Ping timeout: 248 seconds]
m5zs7k has quit [Ping timeout: 272 seconds]
m5zs7k has joined #armlinux
Amit_T has joined #armlinux
frieder_ has joined #armlinux
frieder has joined #armlinux
frieder_ has quit [Ping timeout: 256 seconds]
mripard_ has joined #armlinux
headless has quit [Quit: Konversation terminated!]
robinp has quit [Ping timeout: 260 seconds]
robinp has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
guillaume_g has quit [Ping timeout: 240 seconds]
guillaume_g has joined #armlinux
torez has joined #armlinux
rfried is now known as simond
simond is now known as rfried
<ajb-linaro>
does anyone know of a proper spec sheet for graviton 2? e.g. CPU features and architectural extensions? I get the feeling it's v8.2+ a bunch but I can't find anything official
<ajb-linaro>
maz: ^
<maz>
ajb-linaro: it is a Neoverse-N1.
<maz>
(64 of them, to be clear)
<ajb-linaro>
maz: thanks
<ajb-linaro>
hopefully QEMU will surpass the feature set by 7.1 (but not the performance ;-)
<javierm>
geertu: we also discussed this in the past so would be interested in yours as well ^
<broonie>
javierm: We could always load all matching modules?
<javierm>
broonie: I thought that kmod didn't load multiple modules?
<javierm>
or maybe it was that couldn't handle multiple modalias uevent and I'm getting confused...
<javierm>
broonie: but that's a good point, if kmod is able to handle that case and just load all matching modules, a single of table should work
<milkylainen>
Is there any way to stop the kernel from resetting the ethernet phys on reboot nowdays?
<milkylainen>
A while ago the kernel was satisfied with the phys being up, nowdays it seems like it cycles them to make sure it's the way it wants them to be.
<milkylainen>
Which kills my boot time. As it won't bring the phys up until someone touches them (ifup, etc).
<javierm>
broonie: asked demarchi how udev/kmod will handle that case, but you made a great point and if there are no races here, it should work even if SPI at some point report proper a OF modalias
<javierm>
*a proper OF modalias
<geertu>
javierm: Sorry, reading through my holiday email backlog.
<geertu>
javierm: I'd say just introduce solomon,ssd1306 etc. No need for i2c or spi
<geertu>
We already have plenty of IIO sensors and audio codec supporting both i2c and spi using a single compatible valu
<geertu>
milkylainen: And another issue is that the MDIO/PHY layer doesn't deassert the reset line, so it fails to read the PHY ID
<javierm>
arnd: I'm answering here instead because is also relevant to geertu comment
<javierm>
arnd: the problem is that for devices registered through DT, the modalias sysfs entry won't have the bus type, only of:<compatible string tuple>
<geertu>
milkylainen: Hence you need to add "ethernet-phy-idXXXX.XXXX" to its compatible value
<javierm>
arnd: so for example if you have an IC that supports both I2C and SPI, then for both it will be reported something like: of:Nnode_name(null)Cvendor,device
<geertu>
milkylainen: [correction] the MDIO/PHY layer does deassert the PHY reset eventually, but too late for probing
<milkylainen>
geertu: Hmm. I don't think that's the issue. Could be a non state-machine issue too. Could be a specific driver powering down. It's a bit non-symmetrical, the behavior that is.
<milkylainen>
In this case it's an intel igb on an embedded machine.. Found a if (!netif_running) igb_power_down_link in the reset sequence of the driver.
<arnd>
javierm: that's not what I expected to see, but I have not looked in enough detail then. What I do see in the spi modalias_show() is
<javierm>
arnd: but that's actually a bug in the SPI core and something that may be fixed at some point
<javierm>
IOW, for this particular case it may work but just due a happy coincidence and may break in the future
<arnd>
Not sure I'm following the reasoning. Why is it a bug for an spi device to have the spi: prefix in its modalias? That sounds perfectly reasonable to me
<javierm>
arnd: because a) the other subsytems don't do this, only report "platform:", "i2c:", etc if those were registered using platform code, not DT/OF
<javierm>
arnd: b) with DT the of_device_id table is used to match, not a spi_device_id one
<javierm>
so it's strange that the OF table is used to match but no to match module aliases
<arnd>
I can see that it's ambiguous to leave out the vendor part, but as far as I understand, there is no need to keep the modalias stable across kernel versions, so this could be extended to spi:of:vendor,device or something like that
<javierm>
and c) the drivers need an spi_device_id table only to have proper module aliases in the kernel module
<broonie>
arnd: See 96c8395e2166efa86082f3b71567ffd84936439b
<javierm>
arnd: yeah and d) the vendor part is trimmed, only the device used so it could clash if two vendors use the same device name
<javierm>
arnd: but also is a red herring because it could be that supports I2C and other bus that also report proper "of:<vendor,device>"
kbingham has joined #armlinux
<arnd>
ok, I see
<milkylainen>
geertu: Maybe I'm confused. Do the external interfaces differ between phy reset and phy power down? Or is pdown a prerogative of the driver? (why else would the igb have a generic pdown in the reset path?)
<milkylainen>
can't find a pdown in the ethtool interfaces.
<javierm>
arnd: I see two possible solutions to this, 1) have a compatible string with a -$bus suffix for each bus supported (that's what many drivers / DT bindings do and what I tried to do for this driver)
<javierm>
arnd: or encode the bus type in the T: portion of the module alias, i.e: alias: of:N*Ti2cCfoo,bar instead of:N*T*Cfoo,bar
<javierm>
I see that the type is filled if the DT node has a "device_type" property, but that's used only for a few devices...
<geertu>
milkylainen: sorry, no idea
<arnd>
javierm: the T field sounds interesting. Traditionally this meant something different entirely of course, but I suppose we could get away with that, in particular since this is not an ABI that we have to keep stable
<javierm>
arnd: yeah, we would abuse that and not follow the https://www.devicetree.org/specifications/ verbatim but I see that "device_type" is mostly used for CPU, memory and only a few devices
<javierm>
maybe it doesn't really have that much meaning to linux
<javierm>
so buses could fill that and be exposed to modalias
<javierm>
if there's something in the DT, that would get more precedence. But since most devices nodes don't fill it, it would be a no-op for the kernel
<arnd>
device_type is commonly used on older powerpc machines. For PCI devices, I think this is fine, since these are required to use device_type="pci" anyway. Some other ones have device_type="serial" or device_type="network", which is a potential conflict if you have a uart or network device behind spi
<javierm>
arnd: I see
<javierm>
arnd: Ok, so I was talking with mripard about this as well. And I think that we could just go with a single "vendor,device" compatible string without the bus as a suffix for now
<javierm>
arnd: due how SPI reports the module aliases, it would work in practice and if that's ever fixed, then by that time we could had already set "Tspi" so it won't be a problem
<javierm>
arnd: but the DT binding should describe the hardware and robher and geertu are correct that having -i2c or -spi there is not correct from a HW description POV
<arnd>
javierm: it would also still require changing lots of drivers to add a module device table for the of_device_id+bus when today they just list the spi_device_id based table, right?
<javierm>
arnd: tha's correct, yes. But it could be doable. We fixed for I2C a few years ago
<javierm>
that had the same issue
<broonie>
The only person who seems to really care about converting it is Andreas who wasn't exactly being constructive :/
Turingtoast has joined #armlinux
<javierm>
broonie: I see. Just read that thread and agree with Russell and you, it's not acceptable to break a lot of drivers that won't load if SPI suddenly start reporting "of:foo,bar" instead of "spi:bar"
<javierm>
first all in tree drivers and DTS need to be fixed for that change to land
<javierm>
arnd, broonie, geertu, mripard: thanks to all for your feedback. I'll answer in the thread with the plan
<robher>
For FDT, device_type is deprecated and unused for everything but cpu, memory, and pci.
<geertu>
javierm: So how do you distinguish i2c devices from i2c controllers like apple,t8103-i2c and atmel,at91rm9200-i2c?
<geertu>
javierm: and what happens if the i2c device is connected to an i3c bus?
<javierm>
geertu: but i2c controllers won't be in a i2c bus, right? Will probably be in the "platform" bus
<javierm>
geertu: and for i3c then the T will be "Ti3c" and "OF_TYPE=i3c"
<javierm>
geertu: a missing piece is that currently the bus type information is not encoded in the kernel modules, probably we should add that too ?
<geertu>
javierm: but there should be no difference between i2c and i3c
<javierm>
geertu: hmm, that's tricky then. So not sure how to fix this then :)
<javierm>
geertu: for now I'll just go ahead with your suggestion and use the same compatible for everything, for I2C and SPI would work in the meantime but may break in the future
<javierm>
geertu: btw, demarchi told me that udev/kmod work as broonie said, if there are two different modules with the same alias, both are loaded so it's OK
<mwalle>
I just try to enable SPI support on my board which has a 32bit arm CPU. The controller has a 256MiB memory mapped window (actually there are up to three spi controllers). But even with one, I run out of vmalloc space (the default is 240MiB). Now one could 'fix' it by editing the device tree, but I don't think that is the correct way
<mwalle>
(the SoC is a LAN966x and the spi controller is the atmel-qspi)
jlinton has quit [Quit: Client closed]
jlinton has joined #armlinux
<geertu>
mwalle: Looks like you should map a subset (e.g. 16 MiB) of the window?
<mwalle>
geertu: you mean the driver should do that? if i'm not mistaken, the driver is (will be?) used for arm64 (which i guess doesn't have this problem). So it should distisguish between .. uhm arm32 and aarch64? or
<geertu>
mwalle: I'm afraid so
<mwalle>
geertu: are you aware of any best practices here? I'd assume one want that to be big enough to match an attach flash
mripard_ has quit [Quit: leaving]
<mwalle>
at least at the moment, the driver will just return EOPNOTSUPP if you try to access it outside that memory mapped window
<geertu>
mwalle: Not really. The only Renesas arm32 SoC that has such an SPI interface doesn't have enabled support for it. The arm64 SoCs have.
<mwalle>
geertu: which doesn't have that particular problem ;)
<geertu>
However, mwalle Exactly :-)
<mwalle>
geertu: but I presume just making the memory window smaller in the device tree is the wrong approach
<geertu>
mwalle: However, the upstream DTS for one of the boards with such an SoC just maps the FLASH read-only using mtd-rom, relying on U-Boot to configure the SPI controller.
<geertu>
And as the FLASH is only 8 MiB, it doesn't need to map the full window, hence no issue on arm32.
<geertu>
(flash@18000000 corresponds to the "dirmap" part of Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml)
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
headless has joined #armlinux
Misotauros has joined #armlinux
<mwalle>
geertu: thanks, I just spoke with the driver developer, it might be possible to start with a small window and increase it after the flash is probed. And limit the max size of it and fall back to regular spi reads
<robher>
javierm: 'type' is already taken, so I don't think we should repurpose it.
guillaume_g has quit [Quit: Konversation terminated!]
<javierm>
robher: Ok
SallyAhaj has joined #armlinux
Turingtoast has joined #armlinux
matthias_bgg has quit [Ping timeout: 248 seconds]
macromorgan has joined #armlinux
frieder has quit [Remote host closed the connection]
Turingtoast has quit [Client Quit]
Pali has joined #armlinux
headless has quit [Ping timeout: 248 seconds]
headless has joined #armlinux
cleger has quit [Quit: Leaving]
amitk has quit [Ping timeout: 256 seconds]
monstr has quit [Remote host closed the connection]
amitk has joined #armlinux
XV8 has joined #armlinux
headless has quit [Ping timeout: 250 seconds]
headless has joined #armlinux
Grimler has joined #armlinux
nsaenz has quit [Remote host closed the connection]
headless_ has joined #armlinux
headless has quit [Ping timeout: 256 seconds]
headless has joined #armlinux
headless_ has quit [Ping timeout: 240 seconds]
Tokamak has joined #armlinux
headless_ has joined #armlinux
headless has quit [Read error: Connection reset by peer]
headless_ is now known as headless
Turingtoast has joined #armlinux
iivanov has quit [Quit: Leaving...]
headless has quit [Ping timeout: 240 seconds]
headless has joined #armlinux
Turingtoast has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
amitk has quit [Quit: leaving]
Amit_T has quit [Quit: Leaving]
cbeznea has quit [Ping timeout: 250 seconds]
torez has quit [Quit: torez]
headless has quit [Quit: Konversation terminated!]