linux-kernel - Re: [PATCH 01/19] bus/cdx: add the cdx bus driver

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]

Date:   Tue, 17 Jan 2023 15:07:02 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Nipun Gupta <nipun.gupta@....com>
Cc:     robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        rafael@...nel.org, eric.auger@...hat.com,
        alex.williamson@...hat.com, cohuck@...hat.com,
        song.bao.hua@...ilicon.com, mchehab+huawei@...nel.org,
        maz@...nel.org, f.fainelli@...il.com, jeffrey.l.hugo@...il.com,
        saravanak@...gle.com, Michael.Srba@...nam.cz, mani@...nel.org,
        yishaih@...dia.com, jgg@...pe.ca, jgg@...dia.com,
        robin.murphy@....com, will@...nel.org, joro@...tes.org,
        masahiroy@...nel.org, ndesaulniers@...gle.com,
        linux-arm-kernel@...ts.infradead.org, linux-kbuild@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        okaya@...nel.org, harpreet.anand@....com, nikhil.agarwal@....com,
        michal.simek@....com, git@....com
Subject: Re: [PATCH 01/19] bus/cdx: add the cdx bus driver

On Tue, Jan 17, 2023 at 07:11:33PM +0530, Nipun Gupta wrote:
> Introduce AMD CDX bus, which provides a mechanism for scanning
> and probing CDX devices. These devices are memory mapped on
> system bus for Application Processors(APUs).
> 
> CDX devices can be changed dynamically in the Fabric and CDX
> bus interacts with CDX controller to rescan the bus and
> rediscover the devices.
> 
> Signed-off-by: Nipun Gupta <nipun.gupta@....com>
> Signed-off-by: Tarak Reddy <tarak.reddy@....com>

First off, very nice job, I didn't find any obvious issues with this
integration into the driver core.

That being said, why do you want this in drivers/bus/?  Why not
drivers/cdx/ ?

One minor comment to make the code smaller:

> +static int get_free_index(void)
> +{
> +	unsigned long id_map;
> +	unsigned long mask;
> +	int index = 0;
> +
> +	mask  = (1UL << MAX_CDX_CONTROLLERS) - 1;
> +retry:
> +	id_map = cdx_controller_id_map[0];
> +	if ((id_map & mask) == mask)
> +		return -ENOSPC;
> +
> +	index = ffz(id_map);
> +	if (index >= MAX_CDX_CONTROLLERS)
> +		return -ENOSPC;
> +
> +	if (test_and_set_bit(index, &cdx_controller_id_map[0]))
> +		goto retry;
> +
> +	return index;
> +}

Why not just use the idr/ida structure instead?  That will handle all of
that logic for you and get rid of your bit twiddling.

> +/**
> + * struct cdx_dev_params - CDX device parameters
> + * @cdx: CDX controller associated with the device
> + * @parent: Associated CDX controller
> + * @vendor: Vendor ID for CDX device
> + * @device: Device ID for CDX device
> + * @bus_num: Bus number for this CDX device
> + * @dev_num: Device number for this device
> + * @res: array of MMIO region entries
> + * @res_count: number of valid MMIO regions
> + * @req_id: Requestor ID associated with CDX device
> + */
> +struct cdx_dev_params {
> +	struct cdx_controller *cdx;
> +	u16 vendor;
> +	u16 device;

Are these in little endian format in memory?  Or native?  Or something
else?

thanks,

greg k-h