Hi Wolfram, and sorry about the late feedback on this. Didn't have time to process my queue before some holiday last week. On Mon, Jun 12, 2023 at 01:35:26PM +0200, Wolfram Sang wrote: > On Tue, May 23, 2023 at 08:43:06AM +0200, Wolfram Sang wrote: > > This is a proof-of-concept how easy it is to merge those two drivers as > > they are extremly similar. The differences can be abstracted away > > easily. Further work (renaming from 'ubx' to something more generic, > > removing the MTK driver, ...) is postponed until there is agrement that > > merging these drivers is actually wanted. I vote for it, though. I have > > updates to the UBX driver which do make sense for the MTK driver as > > well. Code saving is also a plus. We can always fork into a specific > > driver again if we'd ever need that. > > > > Signed-off-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> > > Johan, just from a gut feeling or a hi level glimpse: is this merging of > the driver worth pursuing? No, sorry, keeping separate drivers per vendor was a deliberate choice. First, some of these devices support vendor specific protocols which we may add driver support for at some point beyond currently just exporting this information to user space (e.g. to change line speed from the driver). Second, device families are expected to share at least some common properties like reset signalling and supplies, which are better kept separate. Johan
Attachment:
signature.asc
Description: PGP signature
