From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8740AC282DC for ; Sun, 2 Jun 2019 09:58:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 56249278B6 for ; Sun, 2 Jun 2019 09:58:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LdCHiT4i" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726416AbfFBJ62 (ORCPT ); Sun, 2 Jun 2019 05:58:28 -0400 Received: from mail-lf1-f67.google.com ([209.85.167.67]:46969 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725953AbfFBJ62 (ORCPT ); Sun, 2 Jun 2019 05:58:28 -0400 Received: by mail-lf1-f67.google.com with SMTP id l26so11250253lfh.13; Sun, 02 Jun 2019 02:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=KXYdQUKOB+u8P8O0FLkc8ya3EQeBwf41WKBLmxzpcZ8=; b=LdCHiT4iF98VJLu5ZMvzSz38dc/ItvhnlFx31mlMK2Vf03KnfWwFAHurWxS9nDTfXH YcC1IeRkfRRjbbSQrK/aWXZiiEFk7LGQaF/FJaljcx3w/Qqlu9QupnVXYK7CRbhS5PpT hdUqNvBFd2jxQROycjwwYDbeM1IMtpJXpKG4RTdyqLHwYW8Xh3ke4mHWBDf+c4Yn3QfU mUB3PStp3TNNvFU6BbeYpD1qZdcqUoEtImPDIyjS2DCB0fqtjgiWB0jXM8saUF+17tLC krLRcqcdtWrvSL65EjEt2exgMdB47g0GiUPV+9MkQ8sHpCna+vxtxtScZGvkpB65VfFN figw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=KXYdQUKOB+u8P8O0FLkc8ya3EQeBwf41WKBLmxzpcZ8=; b=lC5WGA9xM89xfPd4e9BBAzlaFcuPZQxbMButmR338z+uyr7LCB5oAkeVhhmkOeYpGg 1VYNGvGUKUn5A1fW3+Qhr8BDszMfu9ugNwbL4jBtfRTJZ2VdpXV/G5k1wl4/sWbhrZjg QNUOV3CBWXLCBn/9CadIEcMhga+IqR1eVHjZjNrhV2lMBspK/7ZZIwVBduQ1S5Clib9t ySXBuO3eHFy0jib1OkNrfBgh5qdGEFdXhMgKcmJ7AvWOX6gxYssQ9PHqlhRr8/HtL7cJ nA96Zuv3cvZIqt6u/x3dc9sdYk2tHO4r2wF0Xofjk3+PCfpESfL6npqAGrgPxozPtAjL NiIA== X-Gm-Message-State: APjAAAWuAAmxIiTZaFj40xjule8uLbUY5OycAkSSjjOwDYV2OV70ODnF 88XB+mG7WSw+e/ldExm9zym8xBJQGK4= X-Google-Smtp-Source: APXvYqxGmln9Il6VJ+XoG/EXc4W4C3KnoHhayvnOMRO5/QPDWyvfjM+mdMCh6OS1D1GVRiYbnEgijQ== X-Received: by 2002:a19:6e41:: with SMTP id q1mr3115326lfk.20.1559469506305; Sun, 02 Jun 2019 02:58:26 -0700 (PDT) Received: from z50.localnet (109241207190.gdansk.vectranet.pl. [109.241.207.190]) by smtp.gmail.com with ESMTPSA id r11sm1660323ljh.90.2019.06.02.02.58.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Jun 2019 02:58:25 -0700 (PDT) From: Janusz Krzysztofik To: Sakari Ailus Cc: Sakari Ailus , Mauro Carvalho Chehab , Hans Verkuil , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Janusz Krzysztofik Subject: Re: [RFC PATCH 4/5] media: ov6650: Fix frame scaling not reset on crop Date: Sun, 02 Jun 2019 11:58:23 +0200 Message-ID: <11387277.ecJxfdHps5@z50> In-Reply-To: <20190601223754.65soglqayxrblgzl@mara.localdomain> References: <20190526204758.1904-1-jmkrzyszt@gmail.com> <1933971.yMpNBnsSgY@z50> <20190601223754.65soglqayxrblgzl@mara.localdomain> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sakari, On Sunday, June 2, 2019 12:37:55 AM CEST Sakari Ailus wrote: > > ... I realised that the subtle effect of "media: > ov6650: Register with asynchronous subdevice framework" is that the driver > is now responsible for serialising the access to its own data structures > now. Indeed, I must have been not thinking much while preparing it, only following patterns from other implementations blindly, sorry. > And it doesn't do that. Could you submit a fix, please? It'd be good to > get that to 5.2 through the fixes branch. How about dropping that V4L2_SUBDEV_FL_HAS_DEVNODE flag for now? I think that will be the most safe approach for a quick fix. I'd then re-add it together with proper locking in a separate patch later. What do yo think? Thanks, Janusz