linux-kernel - Re: [PATCH v10 3/4] drm/lsdc: add drm driver for loongson display controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220223154134.y7slxu3jaje2jtwr@houat>
Date:   Wed, 23 Feb 2022 16:41:34 +0100
From:   Maxime Ripard <maxime@...no.tech>
To:     Sui Jingfeng <15330273260@....cn>
Cc:     Thomas Zimmermann <tzimmermann@...e.de>,
        Roland Scheidegger <sroland@...are.com>,
        Zack Rusin <zackr@...are.com>,
        Christian Gmeiner <christian.gmeiner@...il.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Andrey Zhizhikin <andrey.zhizhikin@...ca-geosystems.com>,
        Sam Ravnborg <sam@...nborg.org>,
        "David S . Miller" <davem@...emloft.net>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Ilia Mirkin <imirkin@...m.mit.edu>,
        Qing Zhang <zhangqing@...ngson.cn>,
        suijingfeng <suijingfeng@...ngson.cn>,
        linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Randy Dunlap <rdunlap@...radead.org>,
        kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v10 3/4] drm/lsdc: add drm driver for loongson display
 controller

On Wed, Feb 23, 2022 at 11:14:12PM +0800, Sui Jingfeng wrote:
> 
> On 2022/2/23 22:39, Maxime Ripard wrote:
> > On Tue, Feb 22, 2022 at 10:46:35PM +0800, Sui Jingfeng wrote:
> > > On 2022/2/22 16:27, Maxime Ripard wrote:
> > > > > +	if (!of_device_is_available(output)) {
> > > > > +		of_node_put(output);
> > > > > +		drm_info(ddev, "connector%d is not available\n", index);
> > > > > +		return NULL;
> > > > > +	}
> > > > > +
> > > > > +	disp_tims_np = of_get_child_by_name(output, "display-timings");
> > > > > +	if (disp_tims_np) {
> > > > > +		lsdc_get_display_timings_from_dtb(output, &lconn->disp_tim);
> > > > > +		lconn->has_disp_tim = true;
> > > > > +		of_node_put(disp_tims_np);
> > > > > +		drm_info(ddev, "Found display timings provided by connector%d\n", index);
> > > > > +	}
> > > > > +
> > > > > +	connector_type = lsdc_get_connector_type(ddev, output, index);
> > > > > +
> > > > > +	if (output) {
> > > > > +		of_node_put(output);
> > > > > +		output = NULL;
> > > > > +	}
> > > > > +
> > > > > +DT_SKIPED:
> > > > > +
> > > > > +	/* Only create the i2c channel if display timing is not provided */
> > > > > +	if (!lconn->has_disp_tim) {
> > > > > +		const struct lsdc_chip_desc * const desc = ldev->desc;
> > > > > +
> > > > > +		if (desc->have_builtin_i2c)
> > > > > +			lconn->ddc = lsdc_create_i2c_chan(ddev, index);
> > > > > +		else
> > > > > +			lconn->ddc = lsdc_get_i2c_adapter(ddev, index);
> > > > This looks weird: the connector bindings have a property to store the
> > > > i2c controller connected to the DDC lines, so you should use that
> > > > instead.
> > > > 
> > > This is not  weird,  ast, mgag200, hibmc do the same thing.
> > And none of them have DT support.
> > 
> > Maxime
> 
> You are wrong, ast driver have dt support. See ast_detect_config_mode() in
> drm/ast/ast_main.c
> 
> static void ast_detect_config_mode(struct drm_device *dev, u32 *scu_rev)
> {
>     struct device_node *np = dev->dev->of_node;
>     struct ast_private *ast = to_ast_private(dev);
>     struct pci_dev *pdev = to_pci_dev(dev->dev);
>     uint32_t data, jregd0, jregd1;
> 
>     /* Defaults */
>     ast->config_mode = ast_use_defaults;
>     *scu_rev = 0xffffffff;
> 
>     /* Check if we have device-tree properties */
>     if (np && !of_property_read_u32(np, "aspeed,scu-revision-id",
>                     scu_rev)) {
>         /* We do, disable P2A access */
>         ast->config_mode = ast_use_dt;
>         drm_info(dev, "Using device-tree for configuration\n");
>         return;
>     }
> 
>  ....
> 
> }

It doesn't seem to probe from the DT though. It uses 4 properties, and
none of them are documented. It's still a widely different case than
your driver that uses the connector binding, and therefore has access to
the ddc bus there.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)