mchehab: did you update your smatch git repo yesterday?
I'm now getting weird errors with smatch:
  CHECK   /home/hans/work/build/media-git/scripts/mod/empty.c
(null): (null):0 (null)() parse error: parsing 'kernel.sizeof_param'
(null): (null):0 (null)() parse error: problem parsing 'kernel.sizeof_param'
If I use the main smatch repo, then it is fine.
Hmm, last change was 5 days ago.
Perhaps it is to do with the rc6 merge.
odd.
hverkuil: yes. I updated it yesterday
I'm getting those here too... didn't check what's causing it
I'm getting those warnings for a while...
but not sure if those were at linux-next
what changeset of smatch is not producing those warnings?
Re:  [10:28:57] If I use the main smatch repo, then it is fine.
sailus: pin
sailus: ping
mchehab: Pong!
I'm starting to look at v2 of CCS patches...
\o/
on patch 1, besides a trivial request (of changing the order of SPDX header to be the first one at the file)...
for the .txt one
I'm wondering why you decided to store the registers as a .txt file, instead of placing them as .rst
(it should still be easy to parse via script)
if some care would be taken
What would be the reasoning to put them into an rst file?
the main reason is because we're banning .txt files from Documentation/* ;-)
I don't think it'll be useful as user (or developer) documentation.
Hmm.
well, there are actually a few exceptions, but tracking them are hard
Would you be happy with another extension?
This isn't documentation, it's register description.
another extension (like .asc) would solve the issue...
Ack.
although, IMHO, register description could be valuable for developers
I can switch to that.
They'd be better looking at the spec itself.
there are lots of other driver-specific docs with register descriptions
And, if they need the registers, then it's the header or limit files.
stupid question, if the file doesn't end up in the generated documentation, shouldn't it go to drivers/media/i2c/.../ ?
mchehab: Seldom the hardware documentation is as good as it is in case of CCS.
In HTML documentation I think these registers would be more noise than anything useful.
pinchartl: well, it can still be included at documentation, by using something like:
 include:: registers.txt
sailus: ok.
after thinking a little bit, maybe we could just use the include directive
bbiab
meeting
back
sailus: as I was saying, I guess keeping the way it is should be fine, if you add some documentation for the CSS driver and place an include directive there
pinchartl: mixing code with text is not a good idea, IMHO... we only do things like that at staging, and just for the sake of keeping staging self-contained
mchehab: it's not code, it's not documentation... what is it ? :-)
pinchartl: it is documentation... it documents the registers used inside the driver
IMO, it fits better at documentation than outside it
I don't mind much
sailus: let me do this way: I'll review the patches and apply as-is, if I don't find anything more weird
we can later address this specific detail
although I'd like to have a solution for this before the merge window - either adding a ".. include" directive on some ReST file or renaming it
would that work for you?
mchehab: I'd prefer renaming.
I can send a patch on top of the pull request.
ok!
mchehab: Do you think we could merge the second set during this cycle as well?
I've addressed the earlier comments on it, but I was waiting for this pull request to be merged (obviously).
ok
Sounds good.
Subject: smiapp: Import CCS definitions
Import CCS register and limit definitions. These files are generated by a
Perl script based on a text-based register definition file. The generator
is added later in the series.
it was actually added earlier ;-)
I'll fix the comment when applying it
(patch 3)
mchehab: Thanks.
The order used to be different but I forgot to change the commit message.
changed it to:
    media: smiapp: Import CCS definitions
    
    Import CCS register and limit definitions. These files are generated by a
    Perl script based on a text-based register definition file. The generator
    was added on
    commit 1ec0b899c2b7 ("media: ccs: Add the generator for CCS register definitions and limits")
Looks good to me.
+		rval = ____ccs_read_addr_8only(sensor, SMIAPP_REG_ADDR(reg),
+						  len, val);
it sounds weird so many underscores for function names
well, smiapp already that things like that, but imo, we should do some cleanup later on
(won't block merging it due to that)
It's a bit convoluted.
I was thinking of cleaning it up a little, later on.
ok, that will be very much appreciated
I believe the patchset includes some of that already.
I don't remember if there's still something left to do.
I mean the big set with over 100 patches, that is. :-)
yeah, I understood
There are all sorts of different cases where registers are read; usual register reads, before the CCS static data is available, before the sensor is identified etc.
This would be easier if there was just a single device, with single hardware documentation and you could adapt the driver to its "features".
There's also value conversion from *different* non-integer formats.
heh
Another one sent.
mchehab: Sorry bombing you with another set of CCS patches. Feel free to ignore these for now if you think they'll be post-5.11 anyway. There are few changes from the second version of the big, big set (kerneldoc in CCS PLL).
s/Sorry \K/for /
sailus: I'll try to handle it this week.
mchehab: Cool!