linux-kernel - Re: [PATCH v4 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver

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, 03 Jun 2017 20:55:23 +0200
From:   Christian Lamparter <chunkeey@...glemail.com>
To:     Varadarajan Narayanan <varada@...eaurora.org>
Cc:     robh+dt@...nel.org, mark.rutland@....com, mturquette@...libre.com,
        sboyd@...eaurora.org, linus.walleij@...aro.org,
        andy.gross@...aro.org, david.brown@...aro.org,
        catalin.marinas@....com, will.deacon@....com,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-gpio@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, bjorn.andersson@...aro.org,
        absahu@...eaurora.org, sjaganat@...eaurora.org,
        sricharan@...eaurora.org, mraghava@...eaurora.org,
        Ram Chandra Jangir <rjangir@...eaurora.org>
Subject: Re: [PATCH v4 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver

On Saturday, June 3, 2017 12:57:50 PM CEST Varadarajan Narayanan wrote:
> Add initial pinctrl driver to support pin configuration with
> pinctrl framework for ipq8074.
> 
> Signed-off-by: Manoharan Vijaya Raghavan <mraghava@...eaurora.org>
> Signed-off-by: Varadarajan Narayanan <varada@...eaurora.org>
> ---
> +- bias-disable:
> +	Usage: optional
> +	Value type: <none>
> +	Definition: The specified pins should be configued as no pull.
> +
> +- bias-pull-down:
> +	Usage: optional
> +	Value type: <none>
> +	Definition: The specified pins should be configued as pull down.
> +
> +- bias-pull-up:
> +	Usage: optional
> +	Value type: <none>
> +	Definition: The specified pins should be configued as pull up.
> +
> +#define REG_SIZE 0x1000
> +#define PINGROUP(id, f1, f2, f3, f4, f5, f6, f7, f8, f9)	\
> +	{					        \
> +		.name = "gpio" #id,			\
> +		.pins = gpio##id##_pins,		\
> +		.npins = (unsigned int)ARRAY_SIZE(gpio##id##_pins),	\
> +		.funcs = (int[]){			\
> +			msm_mux_gpio, /* gpio mode */	\
> +			msm_mux_##f1,			\
> +			msm_mux_##f2,			\
> +			msm_mux_##f3,			\
> +			msm_mux_##f4,			\
> +			msm_mux_##f5,			\
> +			msm_mux_##f6,			\
> +			msm_mux_##f7,			\
> +			msm_mux_##f8,			\
> +			msm_mux_##f9			\
> +		},				        \
> +		.nfuncs = 10,				\
> +		.ctl_reg = REG_SIZE * id,		\
> +		.io_reg = 0x4 + REG_SIZE * id,		\
> +		.intr_cfg_reg = 0x8 + REG_SIZE * id,		\
> +		.intr_status_reg = 0xc + REG_SIZE * id,	\
> +		.intr_target_reg = 0x8 + REG_SIZE * id,	\
> +		.mux_bit = 2,			\
> +		.pull_bit = 0,			\
> +		.drv_bit = 6,			\
> +		.oe_bit = 9,			\
> +		.in_bit = 0,			\
> +		.out_bit = 1,			\
> +		.intr_enable_bit = 0,		\
> +		.intr_status_bit = 0,		\
> +		.intr_target_bit = 5,		\
> +		.intr_raw_status_bit = 4,	\
> +		.intr_polarity_bit = 1,		\
> +		.intr_detection_bit = 2,	\
> +		.intr_detection_width = 2,	\
> +	}
> +
Hello,

Back in May, Ram Chandra Jangir posted a rather interesting patch on
the LEDE Mailing-List:
<https://www.mail-archive.com/lede-dev@lists.infradead.org/msg07691.html>
|GPIO_PULL bits configurations in TLMM_GPIO_CFG register
|differs for IPQ40xx from rest of the other qcom SoC's.
|This change add support to configure the msm_gpio_pull
|bits for ipq40xx, It is required to fix the proper
|configurations of gpio-pull bits for nand pins mux.
|
|IPQ40xx SoC:
|2'b10: Internal pull up enable.
|2'b11: Unsupport
|
|For other SoC's:
|2'b10: Keeper
|2'b11: Pull-Up

This information wasn't mentioned anywhere. In fact, the special pull-up
configuration was only discovered due to an issue with the qpic NAND on
the Cisco Meraki MR33. So I wonder what does the gpio-pull look like for
the IPQ8074? Is it the same as the IPQ40XX or does it follow the older 
SoCs?

I'm asking this because I'm preparing a modified version of this patch
that will be posted once the IPQ8074 is ready.

Regards,
Christian