Am 06.12.2017 um 14:47 schrieb Dan Carpenter: > On Wed, Dec 06, 2017 at 11:11:27AM +0200, Marcus Wolf wrote: >> >> Since the rule for kernel development seems to be, not to care about future, >> most probably you patch is fine, anyway. >> > > Yeah. Deleting code if there is no user is required to move this code > out of staging... > > I've worked in staging for a long time and I've seen patches from > thousands of people. Simon really seems to understand kernel style and > that's less common than one might think. It's a valuable skill. If you > would just leave him to work then this driver would get fixed... > > You're making it very difficult because you're complaining about the > work which *needs* to be done. It's discouraging for people sending > patches. This is very frustrating... :( > > On the naming, I think having a function which is named "enable" but > actually disables a feature is a non-starter. What about we do either > one of these: > pi433_enable_<feature>(spi); > pi433_disable_<feature>(spi); > Or: > pi433_set_<feature>(spi, SETTING); > > It's still a standard and we'll just decide on a case by case basis what > to use. This is a tiny driver and it's really easy to grep for the > feature name to find the functions you want. Plus all the config is > done in one location so it's really not that hard. > > regards, > dan carpenter > Hi Greg, Dan, Simon and all others, yesterday we had a project meeting. Though I am the boss, I was "punished" that I spend such a bunch of time to discuss here, instead of finishing stuff from my todo list :-P I get the point, that I am not really deep in the kernel style guide and it is better, if I don't disturb the nerds. Both facts in combination tell me, that I should lean back, wait a while and see, what the driver will become. On the other hand, my team was - like me - a little bit in worry about this "closing a door", that happend a few times during the last weeks and the possible redesign of the driver architecture. It would be pitty, if the effort for integration of new features will be complicated a lot. We finally decided, that I actually should reduce focussing on the driver for the moment and let things go. We'd like to use this mail, to tell our ideas and the plan for next year: When submitting the driver, we wanted to add support to the kernel for the technical really good modules from HopeRf. The idea was to support serveral chips and several modules (carrying those chips). Due to financial and time restrictions, we finally had to reduce to rfm69cw and focused on Pi433. Plan for the next year: * Tweak the driver (if needed) to enable the reception of telegrams without preamble and sync pattern. We never tested this before. This feature will be needed aprox. in March'18. * Support for the rfm69cw-868 - Almost the same module as the current, but for the 868MHz ISM band. Will be needed approx. end of summer next year. * We would like to add support for some more features of the chip (e. g. AES) - you can see, there are lots of so far not covered registers (commented lines in rf69_registers.h). No shedule for this. * If we will have a (financially) successfull 2018, we think about integration of the rf95 chip. >From third parties we were asked about the follwoing features: * Implement support for continuous mode (e. g. from projects fhem, domotics). * Do a little bit more generic inteface implementation, to also support other hardware setups, using the rf69 chip. Second sounds very interesting - especially in terms of a real Linux driver. But both topics so far aren't on our agenda. So I will withdraw from the development of pi433 driver for the next monthes and will be back at the beginning of spring. I hope, there are not too many closed doors, so I can easily start over with head rev. and don't have to fall back to my old base. To ease a start over, I would love the following things (as much, as possible without breaking the rules): * do not modify the register abstraction in a way, that it doesn't represent the real hardware any more (e. g. the stuff with amp - the chip does not have two registers, taking chipnumbers, but 3 bits, taking on/off information). In doubt have a look at the data sheet. * stay with the naming convention for the register abstraction (rf69_set_... and rf69_get_...). If for some reason a register (or bit) needs to be read back for some reason in future, it is unlovely to have rf69_do_something and you need to find a adequate name for the getter. rf69_get_do_something is ugly most times. * if possible, do not remove my tiny "debug system" in the register abstraction. It's very powerfull, if you work on config changes. * try to keep the current or find a new way, that a setting from user space could be mapped to (not identical) register sets of different chips. If you have any questions - especially concerning the hardware facts - feel free to ask. To be sure, I don't miss the mail between others from the mailing list, write something like Hi Marcus! in the first line or even in the subject. Thanks a lot for your effort! Merry Christmas and a happy new year, Marcus _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
