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]
Message-Id: <201205242338.41420.marc@cpdesign.com.au>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ