19:10 <xdarklight> webczat: in theory: yes, but I think nobody has tested it yet. to make it work: https://elixir.bootlin.com/linux/v4.16.8/source/drivers/mmc/host/meson-gx-mmc.c#L1255 -> change "mmc->caps |= MMC_CAP_CMD23;" to "mmc->caps |= MMC_CAP_CMD23 | MMC_CAP_ERASE;"

19:11 <xdarklight> I used MMC_CAP_ERASE in the meson-mx-sdio driver (which is used on the 32-bit SoCs) and it works fine(tm), so newer hardware should support it as well

19:33 <steamport> what's the best working meson6 kernel

19:34 <steamport> as in, AMX

20:30 <webczat> xdarklight: well why it is not enabled by default? precisely because untested? or it is not in mainline? also if I would want that how would I recognize that it works? successful result would guarantee it? or whatever

20:31 <webczat> well another thing would be why it is still untested :) is it so dangerous so that it would not be enabled by default until testing?

21:33 <xdarklight> webczat: I'm not sure if file systems enable "discard" by default if it's available. if they do then it can easily lead to data corruption if something is not working right

21:33 <xdarklight> webczat: so yes, it's not enabled by default because it's not tested yet

21:34 <webczat> xdarklight: ok. I can assure you filesystems *never* enable discard by default. and some don't even have that option and you have to use fstrim

21:35 <webczat> ... and there are some that are the opposite where fstrim does not work and you have to mount with discard

21:35 <webczat> vfat is one of them

21:37 <xdarklight> ok, but it can still corrupt data if it's untested functionality and someone enables it (for example after migrating from another system and thus being unaware that adding "discard" is untested on the GX platform)

21:39 <steamport> what's the best working meson6 kernel

21:40 <xdarklight> steamport: mainline boots to early console and nothing else. I'm not sure if there's any "recommendation" for a 3.10 Amlogic kernel (which supports Meson6)

21:40 <steamport> i mean

21:40 <steamport> what 3.10 amlogic kernel would work for a NX008HD8G

21:46 <webczat> xdarklight: sure, but someone somewhere should probably test it. just not quite sure how if I would ever be able to do it

23:03 <khilman> xdarklight: is ethernet on meson8b-odroidc1 working well for you on my v4.18/integ branch?

23:03 <khilman> for me, the kernel boots, and can even DHCP when I add "ip=dhcp" to the cmdline.

23:04 <xdarklight> khilman: interesting, I will re-test with your v4.18/integ branch

23:04 <xdarklight> khilman: with v4.17-rc3 + my Odroid-C1 patches I needed https://patchwork.kernel.org/patch/10374537/ as well

23:04 <khilman> but when I get to a shell (ramdisk), I can't ping anything. 100% packet loss

23:05 <xdarklight> that sounds familiar and https://patchwork.kernel.org/patch/10374537/ "fixes" it for me

23:07 <khilman> ah, I see those mentioned now in your "RGMII Ethernet pin cleanup" thread

23:08 <xdarklight> yep

23:08 <xdarklight> the other two already made it into v4.17-rc(can't remember which one exactly, but I believe 3)

23:12 <khilman> funny, I can't seem to find the original patch in my inbox.

23:12 <khilman> but got it from patchwork, and it works! NFSroot working now on odroidc1

23:15 <khilman> I added that to my "depends" branch (included in integ) until it gets merged.

23:18 <xdarklight> ok, great

23:19 <xdarklight> should I send your Tested-by to the list (and CC you on that reply)?

23:30 <khilman> yes please!

23:32 <xdarklight> mail sent

23:59 <xdarklight> khilman: do you have access to any GXBB board? I'm interested in "cat /sys/kernel/debug/{c9000000,c9100000}.usb/{dr_mode,fifo,hw_params,params,state}" since my own GXBB board died a while ago (I want to know if GXBB suffers from the problem described here: http://lists.infradead.org/pipermail/linux-amlogic/2018-May/007310.html )