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:   Wed, 25 Apr 2018 18:57:30 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Javier Arteaga <javier@...tex.com>,
        Lee Jones <lee.jones@...aro.org>
Cc:     Dan O'Donovan <dan@...tex.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, linux-gpio@...r.kernel.org,
        linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH RESEND 1/3] mfd: upboard: Add UP2 platform
 controller driver

On Sat, 2018-04-21 at 09:50 +0100, Javier Arteaga wrote:
> UP Squared (UP2) is a x86 SBC from AAEON based on Intel Apollo Lake. 

> +config MFD_UPBOARD
> +	tristate "UP Squared"
> +	depends on ACPI
> +	depends on GPIOLIB
> +	select MFD_CORE
> +	select REGMAP
> +	help
> +	  If you say yes here you get support for the platform
> controller
> +	  of the UP Squared single-board computer.
> +
> +	  This driver provides common support for accessing the
> device,
> +	  additional drivers must be enabled in order to use the
> +	  functionality of the device.
> +
> +	  This driver can also be built as a module. If so, the
> module
> +	  will be called upboard.

"upboard"

> 
> +static int upboard_read(void *context, unsigned int reg, unsigned int
> *val)
> +{
> +	const struct upboard * const upboard = context;
> +	int i;
> +
> +	gpiod_set_value(upboard->clear_gpio, 0);
> +	gpiod_set_value(upboard->clear_gpio, 1);
> +
> +	reg |= UPBOARD_READ_FLAG;
> +
> +	for (i = UPBOARD_ADDRESS_SIZE; i >= 0; i--) {
> +		gpiod_set_value(upboard->strobe_gpio, 0);
> +		gpiod_set_value(upboard->datain_gpio, (reg >> i) &
> 0x1);
> +		gpiod_set_value(upboard->strobe_gpio, 1);
> +	}
> +

> +	gpiod_set_value(upboard->strobe_gpio, 0);
> +	*val = 0;
> +
> +	for (i = UPBOARD_REGISTER_SIZE - 1; i >= 0; i--) {
> +		gpiod_set_value(upboard->strobe_gpio, 1);
> +		gpiod_set_value(upboard->strobe_gpio, 0);
> +		*val |= gpiod_get_value(upboard->dataout_gpio) << i;
> +	}
> +
> +	gpiod_set_value(upboard->strobe_gpio, 1);

Can't you rewrite this like

for (addr) {
 strobe(0)
 data(x)
 strobe(1)
}

for (register) {
 strobe(0)
 val = data(x)
 strobe(1)
}

val &= BIT(register_size);
strobe(0)

?

> +
> +	return 0;
> +};
> +
> +static int upboard_write(void *context, unsigned int reg, unsigned
> int val)
> +{
> +	const struct upboard * const upboard = context;
> +	int i;
> +
> +	gpiod_set_value(upboard->clear_gpio, 0);
> +	gpiod_set_value(upboard->clear_gpio, 1);
> +
> +	for (i = UPBOARD_ADDRESS_SIZE; i >= 0; i--) {
> +		gpiod_set_value(upboard->strobe_gpio, 0);
> +		gpiod_set_value(upboard->datain_gpio, (reg >> i) &
> 0x1);
> +		gpiod_set_value(upboard->strobe_gpio, 1);
> +	}
> +
> +	gpiod_set_value(upboard->strobe_gpio, 0);
> +
> +	for (i = UPBOARD_REGISTER_SIZE - 1; i >= 0; i--) {
> +		gpiod_set_value(upboard->datain_gpio, (val >> i) &
> 0x1);
> +		gpiod_set_value(upboard->strobe_gpio, 1);
> +		gpiod_set_value(upboard->strobe_gpio, 0);
> +	}
> +
> +	gpiod_set_value(upboard->strobe_gpio, 1);

Similar here:

for (addr) {
 strobe(0)
 data(x)
 strobe(1)
}

for (register) {
 strobe(0)
 data(x)
 strobe(1)
}

strobe(0)
strobe(1)

?

> +
> +	return 0;
> +};

Moreover these two functions have duplications, i.e.

static ... upboard_clear()
{
 clear(0)
 clear(1)
}

static ... upboard_set_address()
{
 for (addr) {
  ...
 }
}


Additional question is about spi-bitbang and i2c-gpio. Can one of them
be utilized here? Why not?

> +struct upboard_data {
> +	const struct regmap_config *regmapconf;
> +	const struct mfd_cell *cells;
> +	size_t ncells;
> +};

> +static int upboard_init_gpio(struct upboard *upboard)
> +{
> +	struct gpio_desc *enable_gpio;
> +
> +	enable_gpio = devm_gpiod_get(upboard->dev, "enable",
> GPIOD_OUT_LOW);
> +	if (IS_ERR(enable_gpio))
> +		return PTR_ERR(enable_gpio);

> +	gpiod_set_value(enable_gpio, 1);

When do you disable it? Why not?

> +	return 0;
> +}

> +
> +static int upboard_check_supported(struct upboard *upboard)
> +{

> +	const unsigned int AAEON_MANUFACTURER_ID = 0x01;
> +	const unsigned int SUPPORTED_FW_MAJOR = 0x0;

Why to hide here instead of putting at the top of file as defined
constants?

> +	unsigned int platform_id, manufacturer_id;
> +	unsigned int firmware_id, build, major, minor, patch;
> +	int ret;

> +	build = (firmware_id >> 12) & 0xf;
> +	major = (firmware_id >> 8) & 0xf;
> +	minor = (firmware_id >> 4) & 0xf;

> +	patch = firmware_id & 0xf;

For style purposes you can use
(firmware >> 0) & 0xf here

> +static int upboard_probe(struct platform_device *pdev)
> +{
> +	struct upboard *upboard;
> +	const struct acpi_device_id *id;
> +	const struct upboard_data *upboard_data;
> +	int ret;

> +	id = acpi_match_device(upboard_acpi_match, &pdev->dev);
> +	if (!id)
> +		return -ENODEV;
> +
> +	upboard_data = (const struct upboard_data *) id->driver_data;

Use new API for that.

> +MODULE_LICENSE("GPL");

License mismatch.

> +#define UPBOARD_ADDRESS_SIZE  7
> +#define UPBOARD_REGISTER_SIZE 16

> +#define UPBOARD_READ_FLAG     BIT(UPBOARD_ADDRESS_SIZE)

It's not clear why this one is defined in this way.
Comment is needed.

-- 
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Intel Finland Oy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ