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] [day] [month] [year] [list]
Message-ID: <20160921063952.gloauhp76uuuibx6@pengutronix.de>
Date:   Wed, 21 Sep 2016 08:39:52 +0200
From:   Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
To:     Joe Perches <joe@...ches.com>
Cc:     Sascha Hauer <kernel@...gutronix.de>,
        Julia Lawall <julia.lawall@...6.fr>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Shawn Guo <shawnguo@...nel.org>
Subject: Re: iomux-mx3.h: possible macro precedence issue

Hello Joe,

On Tue, Sep 20, 2016 at 11:12:59PM -0700, Joe Perches wrote:
> > > -#define MX31_PIN_DTR_DTE1__DTR_DTE2	IOMUX_MODE(MX31_PIN_DTR_DTE1, IOMUX_OCONFIG_ALT3 | IOMUX_ICONFIG_NONE)
> > > +#define MX31_PIN_DTR_DTE1__DTR_DTE2	IOMUX_MODE(MX31_PIN_DTR_DTE1, (IOMUX_OCONFIG_ALT3 | IOMUX_ICONFIG_NONE))
> > > [...]
> > > -#define IOMUX_MODE(pin, mode) (pin | mode << IOMUX_MODE_SHIFT)
> > > +#define IOMUX_MODE(pin, mode) ((pin) | ((mode) << IOMUX_MODE_SHIFT))
> >
> > Joe, do you create a proper patch?
> 
> I just don't have the hardware and don't know what was intended
> by the existing code.  It does appear to be a defect though.

I don't have that hardware either, but fixing this with just checking
the hardware manual is good enough.

The current definition makes MX31_PIN_DTR_DTE1__DTR_DTE2:

	  MX31_PIN_DTR_DTE1__DTR_DTE2
	= IOMUX_MODE(MX31_PIN_DTR_DTE1, IOMUX_OCONFIG_ALT3 | IOMUX_ICONFIG_NONE)
	= (MX31_PIN_DTR_DTE1 | IOMUX_OCONFIG_ALT3 | IOMUX_ICONFIG_NONE << IOMUX_MODE_SHIFT)
	= (IOMUX_PIN(44, 109) | (4 << 4) | 0 << 17)
	= (0x586d | 0x40)
	= 0x586d

while the expected value is

	  (MX31_PIN_DTR_DTE1 | (IOMUX_OCONFIG_ALT3 | IOMUX_ICONFIG_NONE) << IOMUX_MODE_SHIFT)
	= (IOMUX_PIN(44, 109) | ((4 << 4) | 0) << 17)
	= (0x586d | 0x800000)
	= 0x80586d

The effect is that the input is routed nowhere (which is the case also
with the issue fixed) and output is controlled by the GPIO module
instead of the UART and so the pin doesn't operate as handshaking
signal. (Assuming I interpreted everything correctly which I'm not sure
given that I didn't touch i.MX31 for long and it's different that the
other i.MX SoCs.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ