<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
tfiga: for now we just need the module vendor
<br> it might not be any valuable use case for upstream, though
<br> (sorry for late reply, went home already on that day)
hverkuil: <u>syoung</u>: git grep EPERM Documentation/media/uapi/
<br> It's not used very often. Usually returned for ioctls that require root permissions.
<br> there are some other usages as well, though, usually because some resource is not available. The use of EPERM is somewhat dubious in those cases.
<br> <u>pinchartl</u>: ping
<br> <u>mchehab</u>: do patches for Documentation/devicetree/bindings/media/* go through the media tree or through the devicetree subsystem?
<br> (e.g. https://patchwork.linuxtv.org/patch/45490/)
<br> <u>pinchartl</u>: do you still want me to handle the vsp1 patches? Just checking.
mchehab: <u>hverkuil</u>: they usually are acked by DT people and are merged on our tree
<br> as they're usually associated with other patches
<br> I wouldn't mind acking to merge such patch via some other tree, if are there good reasons for that
hverkuil: <u>neg</u>: finished going through the v8 series. Looks good, except for one small typo I found. If you post a v9 I'll make a pull request. I like to get this out of my queue :-)
pinchartl: <u>hverkuil</u>: there's a single one pending for v4.16, and Kieran is handling it
<br> <u>kbingham</u>: should Hans take the patch in his tree ?
kbingham: <u>pinchartl</u>: Technically there are 2 patches !
<br> <u>pinchartl</u>: One of which I'm waiting on a response from you :)
<br> <u>pinchartl</u>: "Re: [PATCH] v4l: vsp1: Fix function declaration/definition mismatch"
pinchartl: <u>kbingham</u>: replied
kbingham: <u>pinchartl</u>: Thanks
pinchartl: I don't have such a strong opinion, but I think that patch slightly hinders readability
kbingham: <u>pinchartl</u>: hehe I thought you'd say something like that - that's why I didn't want to accept it without you commenting :O)
pinchartl: what's your opinion ?
hverkuil: <u>pinchartl</u>: kbingham: I don't mind who makes the pull request, as long as I know who it is of us three.
pinchartl: if you think it's better to fix the cppcheck warning then I won't reject the patch
hverkuil: I have several vsp1 patches assigned to me, but if you or Kieran are going to do the pull request from now on, then I can re-delegate them.
pinchartl: which one are those ?
hverkuil: https://patchwork.linuxtv.org/patch/45504/
<br> https://patchwork.linuxtv.org/patch/43356/
<br> https://patchwork.linuxtv.org/patch/43215/
pinchartl: the first one is part of a larger series that I still need to review
<br> the second one is the patch that Kieran just mentioned, I don't think we should merge it
<br> the third one is indeed pending. I was considering merging it through the DRM tree actually
<br> I thought I had asked Mauro about that but it appears I haven't
<br> <u>mchehab</u>: would you be OK with https://patchwork.linuxtv.org/patch/43215/ being merged through the DRM tree ?
<br> it's the usual story, part of a series of display-related patches, and won't cause any conflict with anything scheduled on the V4L2 side
<br> I've posted a larger series for the VSP driver yesterday that will also have to go through the DRM tree
<br> and it is based on that patch
<br> so it's easier to merge them all through Dave
kbingham: https://patchwork.linuxtv.org/patch/44328/ is the one I actually want to see get in soon - but the updated patch hasn't appeared on patchwork - so I'll post a v3.
hverkuil: <u>pinchartl</u>: I've reassigned all those patches to you.
pinchartl: they don't depend on anything scheduled for v4.16 on the V4L2 side, but they do depend on patches scheduled for v4.16 on the DRM side
<br> <u>hverkuil</u>: thank you
hverkuil: I'm not delegating any vsp1 patches to me anymore because they all have to be reviewed by you anyway.
pinchartl: I'm fine with that
mchehab: <u>pinchartl</u>: sure. For 43215: Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
hverkuil: Either do the pull request yourself or by Kieran, or delegate them to me when you are OK with it and I'll add them the next time I prepare pull requests.
pinchartl: <u>mchehab</u>: thank you
mchehab: anytime
hverkuil: it's too confusing otherwise for me.
pinchartl: <u>kbingham</u>: feel free to send a pull request for v3
kbingham: <u>hverkuil</u>: pinchartl: Ok - so for this single patch (v3) is just delegating easiest ?
pinchartl: <u>kbingham</u>: probably, if Hans is fine with that
-: kbingham wishes he could bulk supercede patches.!
hverkuil: <u>kbingham</u>: sure, no problem. Let me know when you've done it and I'll add it to my upcoming pull request
kbingham: <u>hverkuil</u>: delgated.
<br> or rather *delegated :D
<br> <u>hverkuil</u>: https://patchwork.linuxtv.org/patch/42937/ is still in my list as delegated to you too ... what's your state on that ?
<br> <u>hverkuil</u>: Do you need me to post a refreshed patch ? or can that go in ?
<br> <u>neg</u>: Did https://patchwork.linuxtv.org/patch/40965/ go in to your tree? or did it get lost ?
hverkuil: <u>kbingham</u>: https://patchwork.linuxtv.org/patch/42937/ has been added to my pull request (had to adjust manually)
kbingham: <u>hverkuil</u>: Thankyou;
neg: <u>kbingham</u>: that patch was not needed as the comparision is dropped in later versions, there is only one subdevice for Gen2 so checking whichone is bound was kind of pointless to begin with :-)
<br> <u>hverkuil</u>: thanks for the review, I will post next version of rcar-vin on wednesday whan I'm back home
hverkuil: OK. If all goes well, then I'll make the pull request on Friday or Monday.
kbingham: <u>neg</u>: Thankyou for the update - I've dropped the patch from patchwork.
hverkuil: <u>gnurou</u>: any update on the new request api code?
werner: Hi folks, I'm posting here because I've tried to send emails to the mailing list and haven't gotten any responses back. I'm either looking for help getting the mailing list to work or direct help with the error I was going to ask the list about.
ndufresne: both could work
<br> better just ask your question
<br> are you ""Werner, Zachary" &
hverkuil: <u>werner</u>: you might have two videobuf2_v4l2 modules in the /lib/modules/`uname -r`directory. If the kernel loads the old one instead of the new, then you can get this error.
<br> (might also be the videobuf2_core module)
werner: I am, and thanks, I'll look
<br> <u>hverkuil</u>: There are old kernel folders that have the modules, but nothing under the current kernel version.
<br> *no duplicates
<br> I am getting a new error now: `videobuf2_core: Unknown symbol v4l_vb2q_enable_media_source (err 0)`
<br> Using the latest code
<br> Which seems like it should be defined in v4l2-mc and then included in videobuf2-core. I don't see where the disconnect is, however.
syoung: hverkuil, mchehab: I would expect the vfs to handle permissions, why would a driver need to check whether something is running as root?
<br> hverkuil, mchehab: what do you think of the various EPERM uses in https://patchwork.linuxtv.org/patch/44961/ (there are more)
awalls1: <u>syoung</u>: EPERM => 'Operation not permitted', EACCES => 'Permission Denied'
<br> http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_03
<br> But yeah EPERM seems wrong
<br> Maybe EBUSY or EAGAIN would be better.
<br> I don't exactly know the context of what the driver is griping about. It appears to be some shared resource or some procedural mistake (something else wasn't set up first) that the driver is griping about.
***: awalls1 has left
mchehab: <u>syoung</u>: awalls is right: EBUSY makes more sense
<br> on most places, at least
<br> + (tps.rate_hp >= CXD2880_DVBT_CODERATE_RESERVED_5) || + (tps.rate_lp >= CXD2880_DVBT_CODERATE_RESERVED_5) || + (tps.hierarchy > CXD2880_DVBT_HIERARCHY_4)) { + return -EPERM; + }
<br> this one, it should likely return -EINVAL
<br> I guess that some conditions there should actually be EINVAL
syoung: awalls-: good point
-: syoung is forgetting his errnos, apparently :/
syoung: some of these EPERM cases are just unreachable code, belt and braces
awalls-: yes, a lot of that code was duplicated in many functions