Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Hi Brian,

Sorry for the delay - had a bit of a crazy week last week.

> I was able to get a new backports package built and running on my
> machine over the weekend.

Nice :)

> First, I did a `./` on Hauke's v5.15.92 release

I didn't even know there was a backports release of the scripts itself
rather than just the output ... :)

> with it's
> corrresponding branch in stable with success and installed backports on
> my hardware running v5.10.0. The new driver code was loaded and worked
> as intended with a couple different usb dongles I have.

Great! So progress, I guess :)

> Second, as a test I built a package release for v5.16.20 because initial
> rtw89 commit appears here:
>   $ pwd
>   /home/bkz/linux-stable
>   $ git symbolic-ref --short HEAD && git rev-parse --short HEAD
>   master
>   ffc253263a13
>   $ git describe --contains e3ec7017f6a20d12ddd9fe23d345ebb7b8c104dd
>   v5.16-rc1~159^2~121^2~39
> I was able to cut that release package that works for the rtw89 driver
> by adjust existing patch file diff hunks to apply properly and adding a
> new header that came in to net.


> What other testing do you recommend for a "new driver" besides testing
> "builds" as mentioned in docs [1] here in 'Adding new driver'?

Well if you have the devices, you could test them too, but ... if we
trust backports to more or less do the right thing, it should work :)

> It goes over supporting latest minor versions and says, "you should install
> all supported kernel with the script in devel/get-compat-kernels and
> then run devel/ckmake to build backports against every kernel version."
> [1]
> I am working on test/automation for our new backports workflow so any
> insight you have would be helpful.

Ah, well, that's more to make sure backports itself (as in the
compatibility code it adds and the changes it makes) actually compiles
against all the different kernels.

You might want to check that, and ckmake and all is just a nicer way of
achieving that. But you might want to restrict yourself to kernels that
you see actually in (broad) use from your users?

> Honestly, we could probably use some key points from this thread to make
> some newbie friendly docs considering how confused I was at first, haha!
> I could probably draw a nice diagram based on your explanations.

I wouldn't mind (you) adding something to the wiki but I'm not even sure
I know how to use it :)


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux