linux-kernel - Re: [PATCH lora-next] net: lora: sx1301: Fix radio SPI write

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:   Mon, 31 Dec 2018 03:52:41 +0100
From:   Andreas Färber <afaerber@...e.de>
To:     Ben Whitten <benwhitten@...il.com>
Cc:     Mark Brown <broonie@...nel.org>, linux-lpwan@...ts.infradead.org,
        Ben Whitten <Ben.Whitten@...rdtech.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH lora-next] net: lora: sx1301: Fix radio SPI write

Am 31.12.18 um 01:14 schrieb Ben Whitten:
> + Mark +linux-kernel
> On Sun, 30 Dec 2018 at 08:45, Andreas Färber <afaerber@...e.de> wrote:
>>
>> When converting to regmap_bus we omitted the write flag,
>> rendering all sx125x register writes no-op.
>>
>> Signed-off-by: Andreas Färber <afaerber@...e.de>
>> ---
>>  drivers/net/lora/sx130x_radio.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/lora/sx130x_radio.c b/drivers/net/lora/sx130x_radio.c
>> index 6c94d13cd4db..e7b2df808c1a 100644
>> --- a/drivers/net/lora/sx130x_radio.c
>> +++ b/drivers/net/lora/sx130x_radio.c
>> @@ -9,6 +9,7 @@
>>   * Copyright (c) 2013 Semtech-Cycleo
>>   */
>>
>> +#include <linux/bitops.h>
>>  #include <linux/of.h>
>>  #include <linux/of_device.h>
>>  #include <linux/regmap.h>
>> @@ -40,7 +41,7 @@ static int sx1301_regmap_bus_write(void *context, unsigned int reg,
>>         ret = regmap_write(priv->regmap, cs, 0);
>>         if (ret)
>>                 return ret;
>> -       ret = regmap_write(priv->regmap, addr, reg);
>> +       ret = regmap_write(priv->regmap, addr, BIT(7) | reg);
> 
> Curious.
> Isn't the (read/write)_flag_mask, set in the regmap_config, a property of
> the device connected to the regmap_bus?

Yes, I assume so.

> I would have expected this to have been applied prior to passing to a
> regmap_bus call, surely the bus should only be concerned with transport?

The argument the regmap_bus ops get is a reg though. It's up to our code
to convert it to an address.

> It will work in our case as our current hardware uses 1 in bit 7 but it
> will not if we ever see other radios with different masks.
> 
> If the regmap_bus provider does need to apply the mask, can we get the
> end device regmap_config and apply it from there?

I did not find a way to retrieve the struct regmap_config or its
.{read,write}_flag_mask values through any regmap helper. Otherwise that
would've been my first choice as well, since we do set it correctly.

We could add a regmap_config* field to struct sx130x_radio_device and
have our probe function populate it, but given that we are implementing
a regmap_bus here, #include "../../base/regmap/internal.h" while ugly
may be the sanest choice. It still requires to add a .regmap field to
struct sx130x_radio_device. Testing on the good interface went positive.

Regards,
Andreas

> Mark what are your thoughts on the route to take?
> 
> Regards,
> Ben Whitten

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)