On Wed, Mar 10, 2021 at 8:20 PM Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > > On Wed, 10 Mar 2021 17:45:35 +0000 > Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > > > On Wed, 10 Mar 2021 19:24:39 +0530 > > Utkarsh Verma <utkarshverma294@xxxxxxxxx> wrote: > > > > > Hello, > > > > > > This is Utkarsh Verma. I am a 3rd year Bachelor of Technology > > > Undergrad in Electronics Engineering from HBTU, Kanpur, India. > > > > > > I want to participate in GSOC this summer, by contributing to the IIO > > > subsystem. But more importantly, I want to be a part of this community > > > and get my hands dirty. > > > > > > I have done the operating system course and know the very basics of > > > Linux Kernel. I have also read some chapters of the "Linux Device > > > Drivers" book. I am very new to the iio subsystem and I am still > > > reading the documentation and the conversation on the mailing list. So > > > if anyone can suggest some easy fixes/tasks for getting started would > > > really be appreciated. > > > > > > I would be really happy to contribute. One thing I've always wanted to do, is to convert the entire IIO subsystem to devm_ variants. Essentially getting rid of the iio_device_unregister() function in favor of using devm_iio_device_unregister() and similar. There's about ~217 uses of this function. The more complicated one is in the 'drivers/platform/x86/toshiba_acpi.c' I think reworking the Toshiba ACPI driver would also be interesting, but it is some work. Now, converting everything to devm_ variants can be considered a bit of an obsession [by some people]. But I sometimes find potential memory leaks by doing this conversion. And chances are that we may never be able to fully convert the IIO API to be devm_ variant-only. But it is an interesting process [for me], just the cleanup itself. Another one, that was interesting until 1-2 years ago, was the conversion of OF drivers to be a bit more ACPI friendly [as well]. This is also a bit of work to convert drivers that use only of_property_read_xxxx() functions to device_property_read_xxx() functions. This isn't always straightforward in all drivers, but I do find it interesting to unify the OF & ACPI interfaces, so that all you have to do, is just switch the system from OF to ACPI underneath, and if the device-tree conversion to ACPI is done right, it just works. Then, there's the matter of moving fields [marked as [INTERN] ) from "struct iio_dev" to "struct iio_dev_opaque". The value of this conversion is to reduce the review pain of having to tell people not-to-use [INTERN] fields [especially when older drivers do]. > > > > > > Regards, > > > Utkarsh Verma > > > > Hi Utkarsh, > > > > Welcome to IIO. > > > > If you want a practical immediate task to make sure you have flow > > of submitting patches etc correct, one issue we've just started seeing > > is that when we do > > > > make W=1 > > > > we get some misleading reports like: > > > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git testing > > > head: 4ef57c4862e38e6034978d8b247a511292d7055a > > > commit: 1cabd1c21b2a6c5b0dd3fdcffe0b24c1d0e4fc38 [72/74] iio: hrtimer: Allow sub Hz granularity > > > config: x86_64-randconfig-a011-20210308 (attached as .config) > > > compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 3a11a41795bec548e91621caaa4cc00fc31b2212) > > > reproduce (this is a W=1 build): > > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > > > chmod +x ~/bin/make.cross > > > # install x86_64 cross compiling tool for clang build > > > # apt-get install binutils-x86-64-linux-gnu > > > # https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?id=1cabd1c21b2a6c5b0dd3fdcffe0b24c1d0e4fc38 > > > git remote add iio https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git > > > git fetch --no-tags iio testing > > > git checkout 1cabd1c21b2a6c5b0dd3fdcffe0b24c1d0e4fc38 > > > # save the attached .config to linux build tree > > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 > > > > > > If you fix the issue, kindly add following tag as appropriate > > > Reported-by: kernel test robot <lkp@xxxxxxxxx> > > > > > > All warnings (new ones prefixed by >>): > > > > > > >> drivers/iio/trigger/iio-trig-hrtimer.c:20: warning: expecting prototype for O periodic hrtimer trigger driver(). Prototype was for PSEC_PER_SEC() instead > > > > > > > > > vim +20 drivers/iio/trigger/iio-trig-hrtimer.c > > > > > > 18 > > > 19 /* Defined locally, not in time64.h yet. */ > > > > 20 #define PSEC_PER_SEC 1000000000000LL > > > 21 > > > > > > > Gwendal figured out what was going on. It's down to an incorrect marking of the > > initial comment block (where copyright notice etc is ) as kernel doc > > by prefixing it with /** > > > > If you'd like to first fine one of those cases and send a patch fixing it that > > would be great. Once we've sanity checked that first one for process issues etc > > you could then ensure there are no other instances in IIO. > > > > No problem if not and you want something more substantial to start with. > > This is just something that hit my inbox today that I'd otherwise clean up, > > but seemed like a good task for anyone wanting to get started! > > Actually scrap that idea. Serves me right for not reading all my IIO related emails > but Gwendal already sent out a patch fixing them all. Sorry! > > Jonathan > > > > > Thanks, > > > > Jonathan >
