Re: [PATCH v4 01/20] platform/x86: x86-android-tablets: convert Goodix devices to GPIO references

[Yauhen Kharuzhy <jekhor@gmail.com>]

On Mon, Feb 09, 2026 at 03:18:55PM +0100, Hans de Goede wrote:
> On 9-Feb-26 15:00, Hans de Goede wrote:
> 
> ...
> 
> > For the drivers/platform/x86/x86-android-tablets/* I think the following
> > fix is both the easiest as well as the best solution is to modify:
> > 
> > drivers/pinctrl/intel/pinctrl-baytrail.c
> > drivers/pinctrl/intel/pinctrl-cherryview.c 
> > 
> > To register a swnode for each GPIO controller and
> > then EXPORT_SYMBOL_GPL an array of fwnode pointers
> > which can then be used in the PROPERTY_ENTRY_GPIO()
> > entries replacing e.g.:
> > 
> > PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[1], 53, GPIO_ACTIVE_HIGH)
> > 
> > with:
> > 
> > PROPERTY_ENTRY_GPIO("reset-gpios", cherryview_gpiochip_fwnodes[1], 53, GPIO_ACTIVE_HIGH)
> > 
> > (these 2 covers pinctrl for the Bay Trail and Cherry Trail x86
> > SoC based Android tablets which x86-android-tablets is for).
> > 
> > This should all be pretty straight forward. Assuming we are allowed
> > to dereference an external symbol for the property initialization
> > if not then this becomes significantly more complex.
> 
> Looking at how the current code works, it does not use an array
> of swnode pointers, it just uses an array of swnodes, and then
> takes the address of the n-th member:
> 
> PROPERTY_ENTRY_GPIO("reset-gpios", &cherryview_gpiochip_nodes[1], 53, GPIO_ACTIVE_HIGH)
> 
> so if we just move the:
> 
> extern const struct software_node baytrail_gpiochip_nodes[];
> extern const struct software_node cherryview_gpiochip_nodes[];
> 
> arrays to the 2 pinctrl drivers and actually associate them
> with / attach them to the GPIO controllers in the pinctrl
> drivers then I think that we will be set for all the references
> to the main SoC GPIO controllers (at the cost of a dependency
> on the pinctrl driver, but that is ok).

OK, but what about additional GPIO chips? For example, on Lenovo YB1-X9*,
sound codec controls additional signals like speaker amplifier
enablling. I did such trick but it looks very... weird: codec device
properties reference fake node for gpiochip which will be created at
driver instantiation (these properties are used by ASoC machine driver
actually):

static const struct property_entry lenovo_yb1_x9x_rt5677_props[] = {
...
	PROPERTY_ENTRY_GPIO("realtek,reset-gpios", &cherryview_gpiochip_nodes[3], 25, GPIO_ACTIVE_LOW),
	PROPERTY_ENTRY_GPIO("realtek,pow-ldo2-gpios", &cherryview_gpiochip_nodes[3], 18, GPIO_ACTIVE_HIGH),
	PROPERTY_ENTRY_GPIO("speaker-enable-gpios", &cherryview_gpiochip_nodes[3], 48, GPIO_ACTIVE_HIGH),
	PROPERTY_ENTRY_GPIO("speaker-enable2-gpios", &lenovo_yb1_rt5677_gpiochip_node, 2, GPIO_ACTIVE_HIGH),
	PROPERTY_ENTRY_GPIO("headphone-enable-gpios", &lenovo_yb1_rt5677_gpiochip_node, 4, GPIO_ACTIVE_HIGH),
	{}
};

static const struct software_node lenovo_yb1_x90_rt5677_node = {
	.properties = lenovo_yb1_x9x_rt5677_props,
};

...
		.board_info = {
			.type = "rt5677",
			.addr = 0x2c,
			.dev_name = "rt5677",
			.swnode = &lenovo_yb1_x90_rt5677_node,
		},
...

https://github.com/jekhor/yogabook-linux-kernel/commit/538313b69483c23afc455571ef638efcea767031#diff-282276fa1330b08656b929c6e956308a122423888b8f07a1d1045e61a813d8c2R159


-- 
Yauhen Kharuzhy