On Wed, Oct 19, 2022 at 05:04:31PM +0200, Bjørn Mork wrote: > Daniele Palmas <dnlplm@xxxxxxxxx> writes: > > I'm aware that rmnet should be the preferred way for qmap, but I think there's > > still value in adding this feature to qmi_wwan qmap implementation since there > > are in the field many users of that. > > > > Moreover, having this in mainline could simplify backporting for those who are > > using qmi_wwan qmap feature but are stuck with old kernel versions. > > > > I'm also aware of the fact that sysfs files for configuration are not the > > preferred way, but it would feel odd changing the way for configuring the driver > > just for this feature, having it different from the previous knobs. > > It's not just that it's not the preferred way.. I believe I promised > that we wouldn't add anything more to this interface. And then I broke > that promise, promising that it would never happen again. So much for > my integrity. > > This all looks very nice to me, and the results are great, and it's just > another knob... > Please no more sysfs files for stuff like this. This turns into vendor-specific random files that no one knows how to change over time with no way to know what userspace tools are accessing them, or if even anyone is using them at all. Shouldn't there be standard ethtool apis for this? > But I don't think we can continue adding this stuff. The QMAP handling > should be done in the rmnet driver. Unless there is some reason it can't > be there? Wouldn't the same code work there? rmnet would be better, but again, no new sysfs files please, thanks, greg k-h
