On Sunday 31 August 2014 01:09:01 Marcel Holtmann wrote: > Hi Pavel, > > >>> What is going on here? I get flamed for not cleaning up > >>> the driver, because I cleaned it up before merging to > >>> -staging. Ok, so I did more cleanups, sent 3 cleanup > >>> patches, no reaction on those, and now I got a note that > >>> you are going to remove the driver...? > >> > >> For the 3 "cleanup" patches, the first one was rejected and > >> you said to not include it, so I couldn't apply the > >> others. > > > > That was different series. I'm talking about: > > > > [PATCH 1/3] staging: nokia_h4: switch to right types and use > > bdaddr_t [PATCH 2/3] staging: nokia_h4: avoid __uX types > > [PATCH 3/3] staging: use inlines where it makes sense > > > > That is still valid and received no comments at all. > > and these are all trivial cleanups and could have been done > back in January when this driver was merged into staging. It > is end of August now and nothing happened to address anything > in the TODO file. > > The warning from end of May that this driver will be removed > seemed to not have triggered anybody to work on the core > issues of the driver. > > There are 3 major topics that needs addressing before this > driver should come anywhere near upstream kernel again, > staging or otherwise. > > a) Convert to using device tree for device detection > > b) Convert to using hdev->setup for firmware loading > > c) Convert to using hdev->set_bdaddr and > HCI_QUIRK_INVALID_BDADDR > > Please keep in mind that this was not an ugly Windows driver > with a lot of Windows specific typedefs or bad coding style > or OS abstractions. From that point of view it was always > good since it was written for Linux in the first place. It > was just a bit dated. Any fixes to bring that in sync with > all other drivers could have been done easily after it was > merged into the Bluetooth subsystem. > > The reason why it ended up in staging is that the 3 core > problems needed fixing. And 8 month later they still have not > been fixed. > > >>> Please don't, I'd still like to clean the driver up and > >>> get included, as n900's are still under active use. > >> > >> As the Bluetooth maintainer has said a number of times, he > >> doesn't want the driver in the tree as it is not doing the > >> correct things. It's been a long time in the tree with no > >> work on it at all, and I follow the suggestions of the > >> maintainers of the subsystems that staging drivers follow. > > > > You asked for more work and explained how easy it is to > > revert the removal. > > > > I did more work, you ignored it, and are removing the > > driver, anyway. > > I have seen only fluff patches. Someone needs to address the > core problems of the driver. > > >> I suggest cleaning this up in your own tree, and then just > >> submitting it for inclusion in the "normal" part of the > >> kernel. That way I'm not > > > > ...creating a mess in the history, and fun merge problems > > for people actually using the driver :-(. And yes, n900 > > people actually are using it and have their own changes on > > top of it. > > That is even worse. We have a staging driver with external > patches on top of it. Getting a driver into staging has an > almost zero barrier and then people still not get their > patches merged into staging. That is just plain said. > > Regards > > Marcel
Hello, external patch is only renaming driver name from btnokia_h4p to hci_h4p - nothing more. And it is only because of Maemo 5 userspace compatibility (which I fix when driver will be in regular bluetooth tree and will be stable). Driver itself is working (with any userspace). So it is not as bad as you think. -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.