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
hanetzer has quit [Ping timeout: 255 seconds]
hanetzer has joined #armlinux
Patater has joined #armlinux
DrPatater has quit [Ping timeout: 255 seconds]
sibis9 has joined #armlinux
Guest1952 has quit [Ping timeout: 255 seconds]
sibis has quit [Ping timeout: 255 seconds]
sibis9 is now known as sibis
nsc has joined #armlinux
nsc is now known as Guest5899
prabhakarlad has quit [Quit: Client closed]
amitk has joined #armlinux
amitk_ has joined #armlinux
amitk has quit [Ping timeout: 248 seconds]
heat has quit [Ping timeout: 248 seconds]
amitk_ has quit [Ping timeout: 248 seconds]
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #armlinux
iivanov_ has joined #armlinux
iivanov has quit [Ping timeout: 248 seconds]
guillaume_g has joined #armlinux
amitk has joined #armlinux
cleger has joined #armlinux
sszy has joined #armlinux
headless has joined #armlinux
cbeznea has joined #armlinux
biju has joined #armlinux
viorel_suman has joined #armlinux
prabhakarlad has joined #armlinux
marc|gonzalez has joined #armlinux
<marc|gonzalez>
narmstrong: hello :)
<marc|gonzalez>
khilman: hello :) I think I found a bug in drivers/mmc/host/meson-gx-mmc.c from 7320915c886180
<narmstrong>
marc|gonzalez: what's the issue ?
<marc|gonzalez>
narmstrong: I have many ;) I wanted to discuss your email answer in IM, if that's cool?
<narmstrong>
marc|gonzalez: yup sure
<marc|gonzalez>
So, in my understanding (which is very limited) the BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_43751, CYW), is only used for the match to start the probe
<narmstrong>
marc|gonzalez: yep
<marc|gonzalez>
then the identification is done by querying the HW on the SDIO bus
<marc|gonzalez>
and that function is sdio_read_cis
<marc|gonzalez>
I put a printk right there, and there's a conversation between the host and ... someone
<marc|gonzalez>
what I don't get is that this "someone" must be the WiFi card, which has its ID stored in some form of ROM/NVRAM
<marc|gonzalez>
Basically, on my board, it looks like two different queries to the same device result in two slightly different answers
<narmstrong>
yep, I don't have the detail on how they implement an SDIO device, but it's basically like an SDCard but it support an extended protocol which is SDIO
<narmstrong>
SDCard also returns cis
<marc|gonzalez>
so what doesn't make sense (to me) is that the host queries the device through the SDIO bus, and the device answers ID=aae7
<marc|gonzalez>
then the host queries the device through a memory mapped register, and the device answers ID=aae8
<marc|gonzalez>
that's pretty confusing, to me, and to the host :p
<marc|gonzalez>
The other issue is commit 7320915c886180 which made meson-gx-mmc probe asynchronously.
<narmstrong>
yep I understand, it's pretty confusing ^^ perhaps it would need a quirk so override the aae8 to aae7 somehow
<marc|gonzalez>
I don't know if there's a race on my board, or if my DT is somehow wrong, but the driver is not binding to the device
<marc|gonzalez>
nothing happens at all, unless I make the probe synchronous, or turn on debug in driver/base/dd.c (which prints a lot of stuff, and delays a lot of stuffà
<narmstrong>
perhaps there's a race with the probe and the wifi card powerup
<marc|gonzalez>
narmstrong: that's a good hypothesis, I'm not sure how to say "wait for the card to be ready before probing", is that PROBE_DEFER?
<marc|gonzalez>
"perhaps it would need a quirk so override the aae8 to aae7 somehow" => I don't even know if the right answer is aae7 or aae8...
<narmstrong>
marc|gonzalez: this doesn't exist on SDIO, except if you mark the port as "removable"
<marc|gonzalez>
narmstrong: what doesn't exist? EPROBE_DEFER?
<narmstrong>
yep if the card isn't present when the port is flagged as "non-removable", the mmc core will stop
<marc|gonzalez>
Probably what's happening... Is marking the card "removable" a sensible solution though?
<marc|gonzalez>
I'll pile this issue in the email thread, as a request for comment, I think
<narmstrong>
you can try, but I don't know the behavior of the asynchronous mmc probe
<marc|gonzalez>
for now I have changed PROBE_PREFER_ASYNCHRONOUS to PROBE_FORCE_SYNCHRONOUS, and it works consistently
<marc|gonzalez>
but it might be only making the race window shorter
marc|gonzalez has quit [Quit: Leaving.]
frieder has joined #armlinux
headless has quit [Quit: Konversation terminated!]
prabhakarlad has quit [Quit: Client closed]
Amit_T has joined #armlinux
prabhakarlad has joined #armlinux
snalty has quit [Ping timeout: 252 seconds]
elastic_dog has joined #armlinux
amitk has quit [Ping timeout: 255 seconds]
elastic_1 has joined #armlinux
elastic_dog is now known as Guest2693
Guest2693 has quit [Killed (mercury.libera.chat (Nickname regained by services))]
elastic_1 is now known as elastic_dog
heat has joined #armlinux
headless has joined #armlinux
amitk has joined #armlinux
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_1 has joined #armlinux
elastic_1 is now known as elastic_dog
Patater has quit [Quit: Explodes into a thousand pieces]
Patater has joined #armlinux
snalty has joined #armlinux
elastic_dog has quit [Ping timeout: 255 seconds]
elastic_dog has joined #armlinux
frieder has quit [Remote host closed the connection]
guillaume_g has quit [Quit: Konversation terminated!]
headless has quit [Quit: Konversation terminated!]
Amit has joined #armlinux
Amit_T has quit [Ping timeout: 255 seconds]
cleger has quit [Remote host closed the connection]