> Date: Tue, 28 Apr 2020 23:27:00 +0200
> From: Patrick Wildt <[email protected]>
>
> On Tue, Apr 28, 2020 at 11:16:43PM +0200, Patrick Wildt wrote:
> > Hi,
> >
> > on my i.MX8MM EVK there's a ath10k-based WiFi chip which we
> > unfortunately do not support (yet?). But the SD/MMC CIS parser
> > complains:
> >
> > sdmmc0: CIS parse error at 4136, tuple code 0x14, length 0
> > manufacturer 0x0271, product 0x0701 at sdmmc0 function 1 not configured
> >
> > It's not a transmission bug though, since I saw prints from a Linux
> > dmesg on the web[0] stating something similar:
> >
> > <4>mmc0: queuing unknown CIS tuple 0x01 (3 bytes)
> > <4>mmc0: queuing unknown CIS tuple 0x1a (5 bytes)
> > <4>mmc0: queuing unknown CIS tuple 0x1b (8 bytes)
> > <4>mmc0: queuing unknown CIS tuple 0x14 (0 bytes)
> >
> > I guess the ath10k-Chips use some vendor-specific tuples in the CIS
> > structure. The thing that our CIS parser complains about is the tuple
> > without a length.
> >
> > Section 16 of the SDIO Simplified Specification 3.0[1] describes the CIS
> > formats, with Section 16.2 describing the Basic Tuple Format. What our
> > code calls "tpllen", the tuple body length, is called "link field" in
> > the specification.
> >
> > The specification explicitly says, that a empty tuple body is fine, by
> > saying: "If the link field is 0, then the tuple body is empty."
> >
> > Thus I propose that instead of complaining about that tuple, we just
> > continue our job. I guess sometimes the existance of a code is infor-
> > mation enough.
> >
> > ok?
> >
> > Patrick
> >
> > [0]
> > https://linuxlists.cc/l/9/linux-wireless/t/3226749/ath10k-sdio:_failed_to_load_firmware
> > [1]
> > https://www.sdcard.org/downloads/pls/pdf/index.php?p=PartE1_SDIO_Simplified_Specification_Ver3.00.jpg&f=PartE1_SDIO_Simplified_Specification_Ver3.00.pdf&e=EN_SSE1
>
> Actually it would be even better to just remove the check, since
> then we would fall into the default case which, given SDMMC_DEBUG
> is on, also lets us know of the unknown tuple:
>
> sdmmc0: unknown tuple code 0x1, length 3
> sdmmc0: unknown tuple code 0x22, length 4
> sdmmc0: unknown tuple code 0x1a, length 5
> sdmmc0: unknown tuple code 0x1b, length 8
> sdmmc0: unknown tuple code 0x14, length 0
> sdmmc0: unknown tuple code 0x22, length 42
> sdmmc0: unknown tuple code 0x80, length 1
> sdmmc0: unknown tuple code 0x81, length 1
> sdmmc0: unknown tuple code 0x82, length 1
>
> The individual switch-cases are checking tpllen properly, so there
> is no harm.
>
> ok?
ok kettenis@
> diff --git a/sys/dev/sdmmc/sdmmc_cis.c b/sys/dev/sdmmc/sdmmc_cis.c
> index 21cf530b24f..70e5b6283a7 100644
> --- a/sys/dev/sdmmc/sdmmc_cis.c
> +++ b/sys/dev/sdmmc/sdmmc_cis.c
> @@ -76,12 +76,6 @@ sdmmc_read_cis(struct sdmmc_function *sf, struct sdmmc_cis
> *cis)
> continue;
>
> tpllen = sdmmc_io_read_1(sf0, reg++);
> - if (tpllen == 0) {
> - printf("%s: CIS parse error at %d, "
> - "tuple code %#x, length %d\n",
> - DEVNAME(sf->sc), reg, tplcode, tpllen);
> - break;
> - }
>
> switch (tplcode) {
> case SD_IO_CISTPL_FUNCID:
>
>
