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:   Sat, 18 Mar 2023 14:07:16 +0800
From:   zhuyinbo <zhuyinbo@...ngson.cn>
To:     Mark Brown <broonie@...nel.org>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-spi@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Jianmin Lv <lvjianmin@...ngson.cn>,
        wanghongliang@...ngson.cn, Liu Peibao <liupeibao@...ngson.cn>,
        loongson-kernel@...ts.loongnix.cn, zhuyinbo@...ngson.cn
Subject: Re: [PATCH v2 2/2] spi: loongson: add bus driver for the loongson spi
 controller


在 2023/3/18 上午12:26, Mark Brown 写道:
> On Fri, Mar 17, 2023 at 04:29:50PM +0800, Yinbo Zhu wrote:
>
>> +static int loongson_spi_update_state(struct loongson_spi *loongson_spi,
>> +				     struct spi_device *spi, struct spi_transfer *t)
>> +{
> ...
>
>> +		loongson_spi->hz = hz;
>> +		loongson_spi->spcr = div_tmp & 3;
>> +		loongson_spi->sper = (div_tmp >> 2) & 3;
>> +		val = loongson_spi_read_reg(loongson_spi, LOONGSON_SPI_SPCR_REG);
> This is writing to general chip registers, apparently not per chip
> select ones.

The loongson_spi_update_state was only be called in setup or transfer_one, and I will also
add a spin lock in tranfser_one.

>
>> +static int loongson_spi_setup(struct spi_device *spi)
>> +{
>> +	struct loongson_spi *loongson_spi;
>> +	spin_lock(&loongson_spi->lock);
>> +	loongson_spi_update_state(loongson_spi, spi, NULL);
> As IIRC I mentioned last time setup() might be called while other
> transfers are happening and therefore shouldn't affect parallel
> operations on other devices.
I think add spin_lock in  transfer_one interface that should be to fix 
this issue, Do you think so?
loongson_spi_transfer_one(struct spi_controller *ctrl, struct spi_dev
  {
         struct loongson_spi *loongson_spi = 
spi_master_get_devdata(spi->master);

+       spin_lock(&loongson_spi->lock);
         loongson_spi_update_state(loongson_spi, spi, xfer);
+       spin_unlock(&loongson_spi->lock);

>
>> +static const struct of_device_id loongson_spi_id_table[] = {
>> +	{ .compatible = "loongson,ls2k-spi", },
>> +	{ }
>> +};
>> +MODULE_DEVICE_TABLE(of, loongson_spi_id_table);
>> +
>> +static struct platform_driver loongson_spi_driver = {
>> +	.probe = loongson_spi_platform_probe,
>> +	.driver	= {
>> +		.name	= "loongson-spi",
>> +		.owner	= THIS_MODULE,
>> +		.bus = &platform_bus_type,
>> +		.pm = &loongson_spi_dev_pm_ops,
>> +		.of_match_table = loongson_spi_id_table,
>> +	},
>> +};
>> +
>> +#ifdef CONFIG_PCI
>> +static int loongson_spi_pci_register(struct pci_dev *pdev,
>> +			const struct pci_device_id *ent)
> Again as I said last time the two buses should probably be separate
> modules.
>
> Otherwise this looks fine.
okay, I will do it.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ