linux-kernel - Re: mc13xxx-core: kernel hangs after 'regmap

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:	Thu, 24 May 2012 23:38:41 +1000
From:	Marc Reilly <marc@...esign.com.au>
To:	Fabio Estevam <festevam@...il.com>
Cc:	Shawn Guo <shawn.guo@...escale.com>,
	"Uwe Kleine-König" <u.kleine-koenig@...gutronix.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Sascha Hauer <kernel@...gutronix.de>,
	Philippe Rétornaz <philippe.retornaz@...l.ch>,
	"linux-kernel" <linux-kernel@...r.kernel.org>
Subject: Re: mc13xxx-core: kernel hangs after 'regmap_read'

Hi,

> Yes, you are right. buf_size should be changed as you suggests so that
> it can be 4 bytes instead of 3.
> 
> This is the patch I am using now:

I just sent something similar before I saw this.

> 
> diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
> index 0bcda48..6beef98 100644
> --- a/drivers/base/regmap/regmap.c
> +++ b/drivers/base/regmap/regmap.c
> @@ -246,11 +246,12 @@ struct regmap *regmap_init(struct device *dev,
>  		map->lock = regmap_lock_mutex;
>  		map->unlock = regmap_unlock_mutex;
>  	}
> -	map->format.buf_size = (config->reg_bits + config->val_bits) / 8;
>  	map->format.reg_bytes = DIV_ROUND_UP(config->reg_bits, 8);
>  	map->format.pad_bytes = config->pad_bits / 8;
>  	map->format.val_bytes = DIV_ROUND_UP(config->val_bits, 8);
> -	map->format.buf_size += map->format.pad_bytes;
> +	map->format.buf_size = (config->reg_bits + config->val_bits +
> +						(config->pad_bits % 8)) / 8;
> +

This won't work when pad bits is > 8


>  	map->reg_shift = config->pad_bits % 8;
>  	if (config->reg_stride)
>  		map->reg_stride = config->reg_stride;
> diff --git a/drivers/mfd/mc13xxx-spi.c b/drivers/mfd/mc13xxx-spi.c
> index 3fcdab3..4c14dfc 100644
> --- a/drivers/mfd/mc13xxx-spi.c
> +++ b/drivers/mfd/mc13xxx-spi.c
> @@ -49,6 +49,8 @@ static struct regmap_config mc13xxx_regmap_spi_config = {
>  	.reg_bits = 7,
>  	.pad_bits = 1,
>  	.val_bits = 24,
> +	.write_flag_mask = 0x80,
> +	.read_flag_mask = 0x00,
> 
>  	.max_register = MC13XXX_NUMREGS,
> 
> @@ -73,7 +75,6 @@ static int mc13xxx_spi_probe(struct spi_device *spi)
> 
>  	dev_set_drvdata(&spi->dev, mc13xxx);
>  	spi->mode = SPI_MODE_0 | SPI_CS_HIGH;
> -	spi->bits_per_word = 32;
> 
>  	mc13xxx->dev = &spi->dev;
>  	mutex_init(&mc13xxx->lock);
> 
> , which is still not allowing me to read the SPI registers correctly.
> 
> Have I missed anything?


If I had something to test with, I'd be looking at the parameters of 
"regmap_spi_read" in drivers/base/regmap/regmap-spi.c . Verify reg_size is 1 
(8bits) and val_size is 3. Check also what the reg address is. The first read 
when the mc13xxx is probed is register 46, so would expect reg to be 0x5C.

> 
> Still reading 0x810 for all registers (0x810000 is the value of
> register 0 , btw).


This could mean that all the registers are being sent as 0 and the value is 
shifted by 12 bits. (which is a bit weird). It's also a strange that Shawn's 
board seems to work.

Do you have any other devices on that SPI that you can verify are working 
correctly? (you said it worked from the bootloader, I'm running out of 
ideas... :| )


Cheers,
Marc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/