Em Fri, 28 Jan 2022 21:01:12 +0200 Sakari Ailus <sakari.ailus@xxxxxx> escreveu: > Hi Mauro, > > On Fri, Jan 28, 2022 at 07:53:12PM +0100, Mauro Carvalho Chehab wrote: > > Em Mon, 24 Jan 2022 18:13:38 +0200 > > Sakari Ailus <sakari.ailus@xxxxxx> escreveu: > > > > > Hi Mauro, > > > > > > Here's a bunch of patches again for 5.18. Most notably there's V4L2 fwnode > > > / mbus_config cleanup by Laurent, the hi847 camera sensor driver from Shawn > > > Tu and the od08d10 camera sensor driver by Jimmy Su. Fixes elsewhere are > > > included, too. > > > > > > Since v1, a few more patches have been added and I've dropped a camss patch > > > already picked by Hans. > > > > > > Please pull. > > > > > > > > > The following changes since commit 68b9bcc8a534cd11fe55f8bc82f948aae7d81b3c: > > > > > > media: ipu3-cio2: Add support for instantiating i2c-clients for VCMs (2021-12-16 20:58:56 +0100) > > > > > > are available in the Git repository at: > > > > > > git://linuxtv.org/sailus/media_tree.git tags/for-5.18-1.1-signed > > > > > > for you to fetch changes up to a6876b00e5daa786a406db09f214bbbb4d1f200c: > > > > > > media: i2c: dw9714: add optional regulator support (2022-01-22 18:27:43 +0200) > > > > > > ---------------------------------------------------------------- > > > V4L2 patches for 5.18 > > > > > > ---------------------------------------------------------------- > > > Angus Ainslie (1): > > > media: i2c: dw9714: add optional regulator support > > > > > > Benjamin Gaignard (1): > > > MAINTAINERS: Update Benjamin Gaignard maintainer status > > > > > > Bingbu Cao (1): > > > media: ov2740: identify module after subdev initialisation > > > > > > Janusz Krzysztofik (4): > > > media: ov6650: Fix set format try processing path > > > media: ov6650: Add try support to selection API operations > > > media: ov6650: Fix crop rectangle affected by set format > > > media: ov6650: Fix missing frame interval enumeration support > > > > > > Jimmy Su (1): > > > media: i2c: Add ov08d10 camera sensor driver > > > > > > Laurent Pinchart (9): > > > media: pxa_camera: Drop usage of .set_mbus_config() > > > media: i2c: ov6650: Drop implementation of .set_mbus_config() > > > media: v4l2-subdev: Drop .set_mbus_config() operation > > > media: v4l2-fwnode: Move bus config structure to v4l2_mediabus.h > > > > > media: v4l2-mediabus: Use structures to describe bus configuration > > > media: v4l2-mediabus: Drop legacy V4L2_MBUS_CSI2_*_LANE flags > > > media: v4l2-mediabus: Drop legacy V4L2_MBUS_CSI2_CHANNEL_* flags > > > media: v4l2-mediabus: Drop V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag > > > > (Some of?) those broke build today: > > https://builder.linuxtv.org/job/media_stage_clang/412/ > > > > Probably due to a conflict some other pull request. > > > > So, I dropped them. Please rebase and re-submit. > > It seems patches got merged that make use of [gs]et_mbus_config that is > changed by the patches. This isn't a very commonly used interface so > there's a bit of bad luck here. > > I'll see what needs to be changed there. Yeah, patches that change kAPI have the potential of getting such kind of conflicts. Thankfully we have now the media_stage tree, and Jenkins builds are working properly. So we were able to solve it before reaching linux-next. No harm done. > Please prioritise these on the next time, if possible. (c/c the other media maintainers) Sure. I usually priorize PRs that solve issues on previous one. Yet, the order is not really important. I mean, if I end merging two PRs again at the same day and one causes breakage on another due to kAPI changes, no matter where PR gets merged early, I would still get a Jenkins compilation error again, and the sanest way to solve such kind of conflicts is to drop the kAPI changes. So, what we need to do, instead, is to coordinate such changes with other maintainers and developers in order to ensure that everyone that would rely on a deprecated kAPI that will be dropped will base their series on the top of the tree with the replacement kAPI. Maybe we could start doing some annotations at the kAPI docs about any plans to deprecate such interfaces at least one or two kernel versions before actually applying the old API removal. Comments? Thanks, Mauro
