Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp10661159ybi; Thu, 11 Jul 2019 08:57:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqyRtyHF58mrT/kwkG6E6XLc3PTpVe2KsDFlMSpWPOg9yqZ5yyfetV9RXHoiO6ZC/aZZek6o X-Received: by 2002:a17:902:7088:: with SMTP id z8mr5526467plk.125.1562860631960; Thu, 11 Jul 2019 08:57:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562860631; cv=none; d=google.com; s=arc-20160816; b=Vm6mhpW4PjBcpilMXR40ycE2rz8pnIIs6WFrfGhhsmn5GF+S5294Hr+ooOiQhcxHFX aDihMHhTWd9uf6f3CrrbSd7E3sE5xdCfxGwKgvkkiykKTjO3HPittaFZ3NE9YAcJcW0q BSPWBQkB6+XkaCTkmhiqRy/+gpWlsUR4qufAbGmL8TsGGccncFwrz+6T22aBPEtry8N+ shshJURjj1e38zzwibrb7QIUQiIMBf4NTrQU6qUc9z1FH+IZMkdR5OxM0JTk9CCEzwFM +H7QtUB47KZzhTBpKQKsBx2DZlPY6OpXF/gNkeh0/1SvoBZNlgix+wRc6zPo3/4mCZAb dUkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=yBVyR6ZJ0iQUUa+9rzC5FP5zydV7ynjfxBMM816XPLM=; b=ayLnvElVcTL6VN9JGW3QaOHLJrKoI/3Ud3Aqi5mloOYyKnLchASnLn6XXOPFhFNsOZ KvFFYPI+KAAQNZbT2128Mj+OZZ0dXy4yGG+KXdCtUvKEA/aCfCxxMvay8alVhh0fRO0P Xxp+ANa9bIlCEo068X0og49dsXOV2biivH+lqU+CVEDrAMycBSgj4Um5Yze6Ghle+qbJ OTLSRwBz2VWZz11xS9jkCR6NtBK7FjVk7+ea9tP4N7e5Sg4XigmvGq3S8wM6Ih/qbRgd PJQgdXpkHyl7JwcVBhNaUq5HOpEvKbscE+J2yK1bjRuHPledoZz1Rj1NZDAtNI+gCp9w nj6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ebzoQHp2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w6si5353898pjr.100.2019.07.11.08.56.56; Thu, 11 Jul 2019 08:57:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ebzoQHp2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728488AbfGKPzJ (ORCPT + 99 others); Thu, 11 Jul 2019 11:55:09 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:43437 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728471AbfGKPzI (ORCPT ); Thu, 11 Jul 2019 11:55:08 -0400 Received: by mail-lj1-f195.google.com with SMTP id 16so6290700ljv.10; Thu, 11 Jul 2019 08:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yBVyR6ZJ0iQUUa+9rzC5FP5zydV7ynjfxBMM816XPLM=; b=ebzoQHp2Iefm7DqbiL2uxAJ0FnEG+6T5H0RDLOMUGDGgZVDCpdCAncry3BSUzYCnRi CuwLx4Rnd5cUdD1kLLQYO78a+AhFBDdDeXJdzAFl1xZ54sSoGHCMa6aSwxBbm89tOPXh nowuvtlI7QbRLokizmjukvfCImbXMsk0vzP64RtWiUn2bfyM3OZkldpQvye+P036TZGa S1S+q0CbObjfU0VDgnwYVALBvqrxZt4yfRd+k0bu566Jqu8ZvfwwHAfAyeqI/LTL1Fvv AuWeykkthtJuacGxjmFT9A7hobTPPaoB/YdHyOQMhBIjXxDYGzDBI/6GBrgGufluCAmm JSBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yBVyR6ZJ0iQUUa+9rzC5FP5zydV7ynjfxBMM816XPLM=; b=OZ61xa0wUE1bG7EcyMvaa1STygjlM9F/VCvFhT8gjoI5ajOM7w5LDNArvVJZHFhAkw Zj5iaiMcjWaLvQoMWquijiC7sVYN7h3utoVoA7S3tWwZHnwFlw3gvwZgWGT/b2wTGWrg iRpM3kTvDsD6Q+IoI3K4cC8PTaPzcthVwpuKG+4BbgqmuQSUMZPu/2FHRvs409i2I/H6 vJ+W9t04N4vWaCfZ7JsLUIm+cQfY2oyOKvBNSmfe1soPunT+iS9QjC3UuloEEOTMsr/k RfDmTNSBwWWS2OBZSluM7dpX0EgZMNkL+P9QKnigc91fSWnVM2FuvnPclYGJyAyu/DMs SNoQ== X-Gm-Message-State: APjAAAUTS/eQ2+H+EOXHbqOg35s1uN0/FM+iwc1pKYqTkZE9R7BZ6LOs GZjyyo9frPYrgPIO7adZhBaLNlEE X-Received: by 2002:a2e:6348:: with SMTP id x69mr3029754ljb.186.1562860506034; Thu, 11 Jul 2019 08:55:06 -0700 (PDT) Received: from [192.168.2.145] (ppp79-139-233-208.pppoe.spdop.ru. [79.139.233.208]) by smtp.googlemail.com with ESMTPSA id a70sm1032963ljf.57.2019.07.11.08.55.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 08:55:05 -0700 (PDT) Subject: Re: [PATCH v1] drm/modes: Skip invalid cmdline mode To: Maxime Ripard Cc: Thierry Reding , Jonathan Hunter , Maarten Lankhorst , Sean Paul , Daniel Vetter , David Airlie , dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org References: <20190709145151.23086-1-digetx@gmail.com> <20190710101229.54ufuhmh22dfxclr@flea> <4ad69d15-07f8-9753-72d6-a51402c94c20@gmail.com> <20190710125552.qvmnh6qs63ikiu2k@flea> <20190710130615.gvi2jwgr2cds66xr@flea> <75719cad-c65c-7ebc-3ea8-98134f86ddc3@gmail.com> <4a13f12f-05a7-473e-4e4e-7a7e32d09720@gmail.com> <20190710140504.t5lsk36gnn5cdn6b@flea> <20190711090327.keuxt2ztfqecdbef@flea> From: Dmitry Osipenko Message-ID: Date: Thu, 11 Jul 2019 18:55:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190711090327.keuxt2ztfqecdbef@flea> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 11.07.2019 12:03, Maxime Ripard пишет: > On Wed, Jul 10, 2019 at 06:05:18PM +0300, Dmitry Osipenko wrote: >> 10.07.2019 17:05, Maxime Ripard пишет: >>> On Wed, Jul 10, 2019 at 04:29:19PM +0300, Dmitry Osipenko wrote: >>>> This works: >>>> >>>> diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c >>>> index 56d36779d213..e5a2f9c8f404 100644 >>>> --- a/drivers/gpu/drm/drm_client_modeset.c >>>> +++ b/drivers/gpu/drm/drm_client_modeset.c >>>> @@ -182,6 +182,8 @@ drm_connector_pick_cmdline_mode(struct drm_connector *connector) >>>> mode = drm_mode_create_from_cmdline_mode(connector->dev, cmdline_mode); >>>> if (mode) >>>> list_add(&mode->head, &connector->modes); >>>> + else >>>> + cmdline_mode->specified = false; >>> >>> Hmmm, it's not clear to me why that wouldn't be the case. >>> >>> If we come back to the beginning of that function, we retrieve the >>> cmdline_mode buffer from the connector pointer, that will probably >>> have been parsed a first time using drm_mode_create_from_cmdline_mode >>> in drm_helper_probe_add_cmdline_mode. >>> >>> Now, I'm guessing that the issue is that in >>> drm_mode_parse_command_line_for_connector, if we have a named mode, we >>> just copy the mode over and set mode->specified. >>> >>> And we then move over to do other checks, and that's probably what >>> fails and returns, but our drm_cmdline_mode will have been modified. >>> >>> I'm not entirely sure how to deal with that though. >>> >>> I guess we could allocate a drm_cmdline_mode structure on the stack, >>> fill that, and if successful copy over its content to the one in >>> drm_connector. That would allow us to only change the content on >>> success, which is what I would expect from such a function? >>> >>> How does that sound? >> >> I now see that there is DRM_MODE_TYPE_USERDEF flag that is assigned only >> for the "cmdline" mode and drm_client_rotation() is the only place in >> DRM code that cares about whether mode is from cmdline, hence looks like >> it will be more correct to do the following: > > I'm still under the impression that we're dealing with workarounds of > a more central issue, which is that we shouldn't return a partially > modified drm_cmdline_mode. > > You said it yourself, the breakage is in the commit changing the > command line parsing logic, while you're fixing here some code that > was introduced later on. The problem stems from assumption that *any* named mode is valid. It looks to me that the ultimate solution would be to move the mode's name comparison into the [1], if that's possible. [1] drm_mode_parse_command_line_for_connector() > Can you try the followintg patch? > http://code.bulix.org/8cwk4c-794565?raw This doesn't help because the problem with the rotation_reflection is that it's 0 if "rotation" not present in the cmdline and then ilog2(0) returns -1. So the patch "drm/modes: Don't apply cmdline's rotation if it wasn't specified" should be correct in any case.