Any workflow suggestion about porting firmware to mainline linux driver?

[Split7fire]

I want to port Chuwi HiBook firmware to work with mainline kernel. I found this https://github.com/torvalds/linux/pull/428/commits/4ca4d58dbccd66baa575f504c67261fdf2900371 It is pretty self-explanatory, but I can't find any info about naming scheme of files. Is it just manufacturer-model or something more (in linux folder there are multiple schemes presented).

P.S. maybe there are some scripts which will auto convert all firmwares to new format?

[onitake]

silead.ko uses firmware in "vanilla" format, so https://github.com/onitake/gsl-firmware/blob/master/firmware/chuwi/hibook/firmware.fw should work. If you need to convert Windows driver firmware instead, please use https://github.com/onitake/gsl-firmware/blob/master/tools/unscramble .

[Split7fire]

ok, I managed to rename fw to gsl3680-chuwi-hibook.fw and place it in /lib/firmware/silead (and in /lib/firmware/ too). I managed to recompile kernel with

static const struct property_entry chuwi_hibook_props[] = {
	PROPERTY_ENTRY_U32("touchscreen-size-x", 1860),
	PROPERTY_ENTRY_U32("touchscreen-size-y", 1280),
	PROPERTY_ENTRY_STRING("firmware-name", "gsl3680-chuwi-hibook.fw"),
	PROPERTY_ENTRY_U32("silead,max-fingers", 10),
	PROPERTY_ENTRY_BOOL("silead,home-button"),
	{ }
};

static const struct silead_ts_dmi_data chuwi_hibook_data = {
	.acpi_name	= "MSSL1680:00",
	.properties	= chuwi_hibook_props,
};

{
 		/* CHUWI HiBook */
 		.driver_data = (void *)&chuwi_hibook_data,
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "svnDefaultstring"),
 			DMI_MATCH(DMI_PRODUCT_NAME, "pnDefaultstring"),
 		},
 	},

but that dont work. Even manually modprobe silead leads to nothing in dmesg. What I've done wrong?

[onitake]

Have you tried unloading the module (modprobe -r silead) before re-insmoding it? You should also make sure that no other silead modules are loaded (i.e. gslx680-acpi, ...).

[Split7fire]

Yep, I tried that with no success. Also it is standard Fedora kernel with patch I made (in silead file). Also this is my dmi info

dmi:bvnAmericanMegatrendsInc.:bvr5.11:bd05/07/2016:svnDefaultstring:pnDefaultstring:pvrDefaultstring:rvnHampoo:rnCherryTrailCR:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:

[onitake]

Hmm... If you unload and reload the module, you should at least see that it's matching the device. If the DMI info is wrong, it will still try to initialise the device with default parameters.

I suspect something is hogging the device and silead.ko can't match it. Can you try blacklisting all related modules, reboot, then try to load the module manually?

[Split7fire]

I can say that silead dont auto load on boot, so it is strange. What related modules can I blacklist?

[onitake]

Well, there's gslx680-acpi, and possibly other competing drivers. I think there's a way to check which driver has claimed a device, but I don't remember how exactly. Possibly through sysfs? You should find the MSSL1680 entry there somewhere, with a symlink to the claiming driver AFAIK.

[Split7fire]

Ok, I managed to build gslx680 acpi module and loaded it. So, it works as expected and shows in dmesg.

gsl_ts_probe: got a device named MSSL0017:00 at address 0x40, IRQ 176, flags 0x0

Maybe the patch I made was defective?

[onitake]

Ok - this is very interesting! It looks like your machine has a touch screen device id that is different from others. Can you replace .acpi_name = "MSSL1680:00", with .acpi_name = "MSSL0017:00", and see if it works?

[Split7fire]

Nope, it didn't work either. And again no log in dmesg.

[onitake]

Then I'm at my wit's end... If you don't get any message at all, that means no driver has matched your hardware. If you can't get silead.ko to at least recognise (and try to initialise) the controller, then you either have different hardware or something is wrong with the ACPI match or your DSDT.

Sorry, it looks like you are on your own...

[maximumsomething]

silead_dmi.c isn't part of the silead.ko module. It has to be compiled into the kernel. You can't just recompile the silead module for your changes to show up, you have to recompile the whole kernel.

[onitake]

Good point... Never thought of that. But it totally makes sense:

config SILEAD_DMI
        bool "Tablets with Silead touchscreens"
        depends on ACPI && DMI && I2C=y && TOUCHSCREEN_SILEAD

@Split7fire , have you tried rebuilding your kernel and rebooting the machine after you have made the changes to silead_dmi.c?

[Split7fire]

@onitake quite a long time passed since that tests. As I remember I do recompile and reboot every time. But for now I can't test it.

[onitake]

I just updated the readme with better instructions for adding support to silead_ts. Any corrections/improvements are welcome.

[onitake]

No further feedback, closing the issue.