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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2337f45f-c513-1b10-ccfc-766363c5fd02@loongson.cn>
Date:   Thu, 23 Mar 2023 20:46:19 +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/21 下午8:08, Mark Brown 写道:
> On Tue, Mar 21, 2023 at 10:54:32AM +0800, zhuyinbo wrote:
>> 在 2023/3/20 下午8:52, Mark Brown 写道:
>>> No, that doesn't help if setup() reconfigures the controller while it's
>>> doing a transfer.  The issue is that the controller might be put into
>>> the wrong mode or run at the wrong speed.
>> sorry, I don't got that why cpu still can call setup's critical region when
>> cpu call transfer_one to  transfer spi data.
>> when I added a spin_lock for setup and transfer_one then setup and
>> transfer_one's critical region cann't be called
>> simultaneously as I know, because the their lock was same lock.
> Think what happens if the two SPI devices have different configurations
> - for example, a different SPI mode.  The register state won't be
> corrupted but the devices will still end up seeing misconfigured SPI
> transfers.

I think add following change and that issue what you said will can be 
fixed,   in addition, the spin_lock

was also not needed.   Do you think so?

@@ -101,8 +101,10 @@ static int loongson_spi_setup(struct spi_device *spi)
         if (spi->chip_select >= spi->master->num_chipselect)
                 return -EINVAL;

+       loongson_spi->hz = 0;
+       loongson_spi->mode &= SPI_NO_CS;
+
         spin_lock(&loongson_spi->lock);
-       loongson_spi_update_state(loongson_spi, spi, NULL);
         loongson_spi_set_cs(spi, 1);


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ