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: <40b4d29e-fa5c-43d5-8ccb-4a5a41150546@linaro.org>
Date: Sat, 6 Jan 2024 16:28:44 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Biju Das <biju.das.jz@...renesas.com>,
 Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
 Banajit Goswami <bgoswami@...cinc.com>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konrad.dybcio@...aro.org>, Liam Girdwood
 <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>,
 Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
 "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
 "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
 "linux-sound@...r.kernel.org" <linux-sound@...r.kernel.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>,
 Sean Anderson <sean.anderson@...o.com>
Subject: Re: [PATCH v2 1/4] reset: gpio: Add GPIO-based reset controller

On 05/01/2024 17:39, Biju Das wrote:
> Hi Krzysztof Kozlowski,
> 
> Thanks for the patch.
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>> Sent: Friday, January 5, 2024 3:59 PM
>> Subject: [PATCH v2 1/4] reset: gpio: Add GPIO-based reset controller
>>
>> Add a simple driver to control GPIO-based resets using the reset
>> controller API for the cases when the GPIOs are shared and reset should be
>> coordinated.  The driver is expected to be used by reset core framework
>> for ad-hoc reset controllers.
>>
>> Cc: Bartosz Golaszewski <brgl@...ev.pl>
>> Cc: Sean Anderson <sean.anderson@...o.com>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>> ---
>>  MAINTAINERS                |   5 ++
>>  drivers/reset/Kconfig      |   9 +++
>>  drivers/reset/Makefile     |   1 +
>>  drivers/reset/reset-gpio.c | 121 +++++++++++++++++++++++++++++++++++++
>>  4 files changed, 136 insertions(+)
>>  create mode 100644 drivers/reset/reset-gpio.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 7fe27cd60e1b..a0fbd4814bc7 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -8866,6 +8866,11 @@ F:	Documentation/i2c/muxes/i2c-mux-gpio.rst
>>  F:	drivers/i2c/muxes/i2c-mux-gpio.c
>>  F:	include/linux/platform_data/i2c-mux-gpio.h
>>
>> +GENERIC GPIO RESET DRIVER
>> +M:	Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>> +S:	Maintained
>> +F:	drivers/reset/reset-gpio.c
>> +
>>  GENERIC HDLC (WAN) DRIVERS
>>  M:	Krzysztof Halasa <khc@...waw.pl>
>>  S:	Maintained
>> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
>> ccd59ddd7610..bb1b5a326eb7 100644
>> --- a/drivers/reset/Kconfig
>> +++ b/drivers/reset/Kconfig
>> @@ -66,6 +66,15 @@ config RESET_BRCMSTB_RESCAL
>>  	  This enables the RESCAL reset controller for SATA, PCIe0, or PCIe1
>> on
>>  	  BCM7216.
>>
>> +config RESET_GPIO
>> +	tristate "GPIO reset controller"
>> +	help
>> +	  This enables a generic reset controller for resets attached via
>> +	  GPIOs.  Typically for OF platforms this driver expects "reset-
>> gpios"
>> +	  property.
>> +
>> +	  If compiled as module, it will be called reset-gpio.
>> +
>>  config RESET_HSDK
>>  	bool "Synopsys HSDK Reset Driver"
>>  	depends on HAS_IOMEM
>> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index
>> 8270da8a4baa..fd8b49fa46fc 100644
>> --- a/drivers/reset/Makefile
>> +++ b/drivers/reset/Makefile
>> @@ -11,6 +11,7 @@ obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o
>>  obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
>>  obj-$(CONFIG_RESET_BRCMSTB) += reset-brcmstb.o
>>  obj-$(CONFIG_RESET_BRCMSTB_RESCAL) += reset-brcmstb-rescal.o
>> +obj-$(CONFIG_RESET_GPIO) += reset-gpio.o
>>  obj-$(CONFIG_RESET_HSDK) += reset-hsdk.o
>>  obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
>>  obj-$(CONFIG_RESET_INTEL_GW) += reset-intel-gw.o diff --git
>> a/drivers/reset/reset-gpio.c b/drivers/reset/reset-gpio.c new file mode
>> 100644 index 000000000000..cf0a867cbc5f
>> --- /dev/null
>> +++ b/drivers/reset/reset-gpio.c
>> @@ -0,0 +1,121 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/mod_devicetable.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/reset-controller.h>
>> +
>> +struct reset_gpio_priv {
>> +	struct reset_controller_dev rc;
>> +	struct gpio_desc *reset;
>> +};
>> +
>> +static inline struct reset_gpio_priv
>> +*rc_to_reset_gpio(struct reset_controller_dev *rc) {
>> +	return container_of(rc, struct reset_gpio_priv, rc); }
>> +
>> +static int reset_gpio_assert(struct reset_controller_dev *rc, unsigned
>> +long id) {
>> +	struct reset_gpio_priv *priv = rc_to_reset_gpio(rc);
>> +
>> +	gpiod_set_value_cansleep(priv->reset, 1);
>> +
>> +	return 0;
>> +}
>> +
>> +static int reset_gpio_deassert(struct reset_controller_dev *rc,
>> +			       unsigned long id)
>> +{
>> +	struct reset_gpio_priv *priv = rc_to_reset_gpio(rc);
>> +
>> +	gpiod_set_value_cansleep(priv->reset, 0);
>> +
>> +	return 0;
>> +}
>> +
>> +static int reset_gpio_status(struct reset_controller_dev *rc, unsigned
>> +long id) {
>> +	struct reset_gpio_priv *priv = rc_to_reset_gpio(rc);
>> +
>> +	return gpiod_get_value_cansleep(priv->reset);
>> +}
>> +
>> +static const struct reset_control_ops reset_gpio_ops = {
>> +	.assert = reset_gpio_assert,
>> +	.deassert = reset_gpio_deassert,
>> +	.status = reset_gpio_status,
>> +};
>> +
>> +static void reset_gpio_of_args_put(void *data) {
>> +	of_node_put(data);
>> +}
>> +
>> +static int reset_gpio_probe(struct platform_device *pdev) {
>> +	struct device *dev = &pdev->dev;
>> +	struct device_node **platdata = dev_get_platdata(dev);
>> +	struct of_phandle_args gpio_args;
>> +	struct reset_gpio_priv *priv;
>> +	int ret;
>> +
>> +	if (!platdata || !*platdata)
> 
> Maybe, if (!(platdata && *platdata)) which reduces 1 inversion operation.

I would not call it easier to understand... To me !A and !*A are quite
obvious and easy to read instantly because !A is obvious: check if it is
not NULL. Therefore original check is obvious: is NULL or points to
NULL? Then exit.

Now your check is a bit more complicated. It is not even frequent code
pattern which my brain used to see. You want to check if both are not
NULL and then negate it, wait, no, opposite, check if they are something
and then negate? To me it is really opposite of readable code.

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ