Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp4548901rdb; Fri, 15 Sep 2023 05:52:05 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGJbqhzGimS+deMwXS9H/cchPGDcJ5xqH9ZLP1011pfdfrzLNHaaMK3Tq/TWIAUO0FXSB40 X-Received: by 2002:a05:6358:2908:b0:13a:4f34:8063 with SMTP id y8-20020a056358290800b0013a4f348063mr1702059rwb.32.1694782325183; Fri, 15 Sep 2023 05:52:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694782325; cv=none; d=google.com; s=arc-20160816; b=UCDDVxDSyo0Xf9dEsjPyt0S2Yo9l77fWexutefdMMmwKqggUAUhBvtC3Sb3GPzDTEj YHlrYBPP5ZTXgL+fsfnmCr1ce6negGdVu13ylkkaRZuOcYN4OF2xF/2TQrrv90/nH3kq 2qwH7g4HTeCgtH1FetYoiWXBvcYZclmRq81JLqc+j0Ah8F1jvOr1xwY4qkpvQqHFEaEp FAMcDf7wwe60Qz+sxWckxIKki6ttEvXfxjqssUqsP23ovnWA3tpRyJ4ng5b2Cv9CVmH8 CUcQQXkAQwOKkbwzQSm3/h/qqU4pQcLJ6MCGl7dCDvctP17FfB97KaGDtgVynzKG2A70 ycXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=9VDOeFLR4TlLZ/YRVcuSLRIQep27lTbJvdpQuLRPCZA=; fh=C1F3SQ8JTPg5BRRYYYr3pMBgszD/sK42W6AHDLlR7gU=; b=XBf8ln2bUF8ZAb2WEIxLo7Kt9Io6loGb6PdHk0FaOxjwmX42Cy91rie8VJ7itvqvoE ZmC31IOhJDynaeWYPsqIQ9dpE6nb9r9Ifmda+IU5m+u1XEN7eDpQrJ2ScTz+TQ5BxxVU GSwSWqulqOMTp6LebQQ9m3yZL1F7XXLwJUrGwM0zQhjGSgdoHZ3ymdgEtEFFFB8YlWm0 zJh67Qx3AwdAIJ/1SOYXcw9wwabnoEZt8nFRB1Et/GZp0clkw3QrPjYFt6f8kXcfMUz1 qJZlmzZTmxAuX6fnICo2fMCJxHqRvk1iNc+KZan4wlV0Fdgtoj9vUczS1DgAMbDLAkAp yrxw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id w20-20020a63fb54000000b00573f786103dsi3108137pgj.754.2023.09.15.05.52.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Sep 2023 05:52:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id E64C78335B0C; Fri, 15 Sep 2023 05:44:55 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235004AbjIOMou (ORCPT + 99 others); Fri, 15 Sep 2023 08:44:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234981AbjIOMou (ORCPT ); Fri, 15 Sep 2023 08:44:50 -0400 Received: from mx.gpxsee.org (mx.gpxsee.org [37.205.14.76]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EB205D3; Fri, 15 Sep 2023 05:44:43 -0700 (PDT) Received: from [192.168.42.133] (host-178-72-203-90.ip.nej.cz [178.72.203.90]) by mx.gpxsee.org (Postfix) with ESMTPSA id A35BE326A6; Fri, 15 Sep 2023 14:44:41 +0200 (CEST) Message-ID: <4b0fe0ec-79fd-42fc-afe8-c44eef471621@gpxsee.org> Date: Fri, 15 Sep 2023 14:44:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RESEND PATCH v9 1/2] Added Digiteq Automotive MGB4 driver Content-Language: en-US To: Hans Verkuil , Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, =?UTF-8?Q?Martin_T=C5=AFma?= References: <20230912120745.902-1-tumic@gpxsee.org> <20230912120745.902-2-tumic@gpxsee.org> From: =?UTF-8?Q?Martin_T=C5=AFma?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Fri, 15 Sep 2023 05:44:56 -0700 (PDT) Hi Hans, On 15. 09. 23 13:50, Hans Verkuil wrote: > Hi Martin, > > On 12/09/2023 14:07, tumic@gpxsee.org wrote: >> From: Martin Tůma >> >> Digiteq Automotive MGB4 is a modular frame grabber PCIe card for automotive >> video interfaces. As for now, two modules - FPD-Link and GMSL - are >> available and supported by the driver. The card has two inputs and two >> outputs (FPD-Link only). >> >> In addition to the video interfaces it also provides a trigger signal >> interface and a MTD interface for FPGA firmware upload. >> >> Signed-off-by: Martin Tůma >> --- > > > >> +static ssize_t video_source_show(struct device *dev, >> + struct device_attribute *attr, char *buf) >> +{ >> + struct video_device *vdev = to_video_device(dev); >> + struct mgb4_vout_dev *voutdev = video_get_drvdata(vdev); >> + u32 config = mgb4_read_reg(&voutdev->mgbdev->video, >> + voutdev->config->regs.config); >> + >> + return sprintf(buf, "%u\n", (config & 0xc) >> 2); >> +} >> + >> +static ssize_t video_source_store(struct device *dev, >> + struct device_attribute *attr, >> + const char *buf, size_t count) >> +{ >> + struct video_device *vdev = to_video_device(dev); >> + struct mgb4_vout_dev *voutdev = video_get_drvdata(vdev); >> + struct mgb4_dev *mgbdev = voutdev->mgbdev; >> + struct mgb4_vin_dev *loopin_new = 0, *loopin_old = 0; >> + unsigned long val; >> + unsigned long flags_in[MGB4_VIN_DEVICES], flags_out[MGB4_VOUT_DEVICES]; >> + ssize_t ret; >> + u32 config; >> + int i; >> + >> + memset(flags_in, 0, sizeof(flags_in)); >> + memset(flags_out, 0, sizeof(flags_out)); >> + >> + ret = kstrtoul(buf, 10, &val); >> + if (ret) >> + return ret; >> + if (val > 3) >> + return -EINVAL; >> + >> + for (i = 0; i < MGB4_VIN_DEVICES; i++) >> + if (mgbdev->vin[i]) >> + spin_lock_irqsave(&mgbdev->vin[i]->vdev.fh_lock, >> + flags_in[i]); >> + for (i = 0; i < MGB4_VOUT_DEVICES; i++) >> + if (mgbdev->vout[i]) >> + spin_lock_irqsave(&mgbdev->vout[i]->vdev.fh_lock, >> + flags_out[i]); > > I missed this in my review: never use fh_lock, that's for internal use only. > > Instead, use the vdev->lock mutex. > >> + >> + ret = -EBUSY; >> + for (i = 0; i < MGB4_VIN_DEVICES; i++) >> + if (mgbdev->vin[i] && !list_empty(&mgbdev->vin[i]->vdev.fh_list)) >> + goto error; > > This is also wrong, the key moment at which such changes are no longer allowed > is when you allocate buffers for the first time. Use vb2_is_busy() to detect that. > > From what I can see in the code most store functions operate on a single video device, > so for those using mutex_lock_interruptible(vdev->lock) and vb2_is_busy() will do the > trick. > Ok, I will change the check to vb2_is_busy() under the vdev->lock for all the "standard" cases (which are all, except the video_source_store() case). > For this store function that needs to check all devices it is more complicated. > > I think the best approach would be to create a top-level field 'reconfig_in_progress' > (or something along those lines), protected by a spinlock. > > At the start this function will take the lock, check if reconfig is already in progress > and just return EBUSY here. Otherwise it sets reconfig_in_progress to true and unlocks > the lock. > > After that for each video device you take the vdev->lock, check if vb2_is_busy() and > unlock vdev->lock. If any is busy, then set reconfig_in_progress back to false and > return EBUSY here. > > To prevent another process from creating buffers, you have to check in the queue_setup > functions if a reconfig is in progress and return EBUSY there. > > This scheme avoids having to lock ALL video devices (bad practice), and it should > also avoid this smatch warning. > Ok, for this "ugly" one configuration I will add a PCIe device-based field and check it in all the v4l2 device's queue_setup() functions. Sounds better than locking all the devices at the same time. Thanks for your help, I will send you a v10 with this two changes (together with the sparse/smatch fixes) soon. M. > Note: instead of using a spinlock I think you can also use test_and_set_bit: that's > atomic and you can avoid adding a spinlock. > > Regards, > > Hans > >> + for (i = 0; i < MGB4_VOUT_DEVICES; i++) >> + if (mgbdev->vout[i] && !list_empty(&mgbdev->vout[i]->vdev.fh_list)) >> + goto error; >> + >> + config = mgb4_read_reg(&mgbdev->video, voutdev->config->regs.config); >> + >> + if (((config & 0xc) >> 2) < MGB4_VIN_DEVICES) >> + loopin_old = mgbdev->vin[(config & 0xc) >> 2]; >> + if (val < MGB4_VIN_DEVICES) >> + loopin_new = mgbdev->vin[val]; >> + if (loopin_old && loopin_cnt(loopin_old) == 1) >> + mgb4_mask_reg(&mgbdev->video, loopin_old->config->regs.config, >> + 0x2, 0x0); >> + if (loopin_new) >> + mgb4_mask_reg(&mgbdev->video, loopin_new->config->regs.config, >> + 0x2, 0x2); >> + >> + if (val == voutdev->config->id + MGB4_VIN_DEVICES) >> + mgb4_write_reg(&mgbdev->video, voutdev->config->regs.config, >> + config & ~(1 << 1)); >> + else >> + mgb4_write_reg(&mgbdev->video, voutdev->config->regs.config, >> + config | (1U << 1)); >> + >> + mgb4_mask_reg(&mgbdev->video, voutdev->config->regs.config, 0xc, >> + val << 2); >> + >> + ret = count; >> + >> +error: >> + for (i = MGB4_VOUT_DEVICES - 1; i >= 0; i--) >> + if (mgbdev->vout[i]) >> + spin_unlock_irqrestore(&mgbdev->vout[i]->vdev.fh_lock, >> + flags_out[i]); >> + for (i = MGB4_VIN_DEVICES - 1; i >= 0; i--) >> + if (mgbdev->vin[i]) >> + spin_unlock_irqrestore(&mgbdev->vin[i]->vdev.fh_lock, >> + flags_in[i]); >> + >> + return ret; >> +} >