netdev - Re: [RFT][PATCH V2 09/10] net: dsa: microchip: Factor out regmap config generation into common header

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, 5 Jan 2019 22:50:48 +0100
From:   Marek Vasut <marex@...x.de>
To:     Tristram.Ha@...rochip.com
Cc:     f.fainelli@...il.com, andrew@...n.ch, Woojung.Huh@...rochip.com,
        netdev@...r.kernel.org
Subject: Re: [RFT][PATCH V2 09/10] net: dsa: microchip: Factor out regmap
 config generation into common header

On 12/21/18 6:23 AM, Marek Vasut wrote:
> On 12/21/2018 05:16 AM, Tristram.Ha@...rochip.com wrote:
>>> +	{								\
>>> +		.val_bits = (width),					\
>>> +		.reg_stride = (width) / 8,				\
>>> +		.reg_bits = (regbits) + (regalign),			\
>>> +		.pad_bits = (regpad),					\
>>> +		.max_register = 0xF00,					\
>>> +		.cache_type = REGCACHE_NONE,
>>> 	\
>>> +		.read_flag_mask =					\
>>> +			KSZ_SPI_OP_FLAG_MASK(KSZ_SPI_OP_RD, regbits,
>>> regpad), \
>>> +		.write_flag_mask =					\
>>> +			KSZ_SPI_OP_FLAG_MASK(KSZ_SPI_OP_WR, regbits,
>>> regpad), \
>>> +		.reg_format_endian = REGMAP_ENDIAN_BIG,
>>> 	\
>>> +		.val_format_endian = REGMAP_ENDIAN_BIG
>>> 	\
>>> +	}
>>
>> max_registers for KSZ9477 should be 0x8000.
>>
>> I found that the SPI access works with these settings:
>> reg_bits = 32 - 5, val_bits = 8, pad_bits = 5, read_flag_mask = KS_SPIOP_RD << 5.
> 
> This is wrong, val_bits must match the register width (8 for 8bit
> regmap, 16 for 16bit regmap etc). Anyway, can you prepare a short diff
> to give me an idea what needs to be changed ?
> 
>> I am using this in another driver running in 4.9.  Somehow the 8-bit write causes the
>> hardware to be in a wrong state.  This is a quick change so there may be bugs in the
>> driver.
> 
> Can you try this as-is on linux-next or net-next ?
> 
>> As expected the access speed is a few microseconds slower than before.
> 
> Why is it expected ?

Bump ?

-- 
Best regards,
Marek Vasut