Hi Stephan,
On Sun, Sep 17, 2023 at 07:05:50PM +0200, Stephan Gerhold wrote:
> Hi Jeff,
>
> Thanks a lot for your detailed review!
Thank you for the productive discussion.
>
> On Sat, Sep 16, 2023 at 03:47:55PM -0500, Jeff LaBundy wrote:
> > On Wed, Sep 13, 2023 at 03:25:30PM +0200, Stephan Gerhold wrote:
> > > From: Jonathan Albrieux <jonathan.albrieux@xxxxxxxxx>
> > >
> > > Add a simple driver for the Himax HX852x(ES) touch panel controller,
> > > with support for multi-touch and capacitive touch keys.
> > >
> > > The driver is somewhat based on sample code from Himax. However, that
> > > code was so extremely confusing that we spent a significant amount of
> > > time just trying to understand the packet format and register commands.
> > > In this driver they are described with clean structs and defines rather
> > > than lots of magic numbers and offset calculations.
> > >
> > > Signed-off-by: Jonathan Albrieux <jonathan.albrieux@xxxxxxxxx>
> > > Co-developed-by: Stephan Gerhold <stephan@xxxxxxxxxxx>
> > > Signed-off-by: Stephan Gerhold <stephan@xxxxxxxxxxx>
> > > ---
> > > MAINTAINERS | 7 +
> > > drivers/input/touchscreen/Kconfig | 10 +
> > > drivers/input/touchscreen/Makefile | 1 +
> > > drivers/input/touchscreen/himax_hx852x.c | 491 +++++++++++++++++++++++++++++++
> > > 4 files changed, 509 insertions(+)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 90f13281d297..c551c60b0598 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -9331,6 +9331,13 @@ S: Maintained
> > > F: Documentation/devicetree/bindings/input/touchscreen/himax,hx83112b.yaml
> > > F: drivers/input/touchscreen/himax_hx83112b.c
> > >
> > > +HIMAX HX852X TOUCHSCREEN DRIVER
> > > +M: Stephan Gerhold <stephan@xxxxxxxxxxx>
> > > +L: linux-input@xxxxxxxxxxxxxxx
> > > +S: Maintained
> > > +F: Documentation/devicetree/bindings/input/touchscreen/himax,hx852es.yaml
> > > +F: drivers/input/touchscreen/himax_hx852x.c
> > > +
> > > HIPPI
> > > M: Jes Sorensen <jes@xxxxxxxxxxxxxxxxxx>
> > > L: linux-hippi@xxxxxxxxxx
> > > diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> > > index e3e2324547b9..8e5667ae5dab 100644
> > > --- a/drivers/input/touchscreen/Kconfig
> > > +++ b/drivers/input/touchscreen/Kconfig
> > > @@ -427,6 +427,16 @@ config TOUCHSCREEN_HIDEEP
> > > To compile this driver as a module, choose M here : the
> > > module will be called hideep_ts.
> > >
> > > +config TOUCHSCREEN_HIMAX_HX852X
> > > + tristate "Himax HX852x(ES) touchscreen"
> > > + depends on I2C
> > > + help
> > > + Say Y here if you have a Himax HX852x(ES) touchscreen.
> > > + If unsure, say N.
> > > +
> > > + To compile this driver as a module, choose M here: the module
> > > + will be called himax_hx852x.
> > > +
> > > config TOUCHSCREEN_HYCON_HY46XX
> > > tristate "Hycon hy46xx touchscreen support"
> > > depends on I2C
> > > diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> > > index 62bd24f3ac8e..f42a87faa86c 100644
> > > --- a/drivers/input/touchscreen/Makefile
> > > +++ b/drivers/input/touchscreen/Makefile
> > > @@ -48,6 +48,7 @@ obj-$(CONFIG_TOUCHSCREEN_EXC3000) += exc3000.o
> > > obj-$(CONFIG_TOUCHSCREEN_FUJITSU) += fujitsu_ts.o
> > > obj-$(CONFIG_TOUCHSCREEN_GOODIX) += goodix_ts.o
> > > obj-$(CONFIG_TOUCHSCREEN_HIDEEP) += hideep.o
> > > +obj-$(CONFIG_TOUCHSCREEN_HIMAX_HX852X) += himax_hx852x.o
> > > obj-$(CONFIG_TOUCHSCREEN_HYNITRON_CSTXXX) += hynitron_cstxxx.o
> > > obj-$(CONFIG_TOUCHSCREEN_ILI210X) += ili210x.o
> > > obj-$(CONFIG_TOUCHSCREEN_ILITEK) += ilitek_ts_i2c.o
> > > diff --git a/drivers/input/touchscreen/himax_hx852x.c b/drivers/input/touchscreen/himax_hx852x.c
> > > new file mode 100644
> > > index 000000000000..31616dcfc5ab
> > > --- /dev/null
> > > +++ b/drivers/input/touchscreen/himax_hx852x.c
> > > @@ -0,0 +1,491 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Himax HX852x(ES) Touchscreen Driver
> > > + * Copyright (c) 2020-2023 Stephan Gerhold <stephan@xxxxxxxxxxx>
> > > + * Copyright (c) 2020 Jonathan Albrieux <jonathan.albrieux@xxxxxxxxx>
> > > + *
> > > + * Based on the Himax Android Driver Sample Code Ver 0.3 for HMX852xES chipset:
> > > + * Copyright (c) 2014 Himax Corporation.
> > > + */
> > > +
> > > +#include <asm/unaligned.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/gpio/consumer.h>
> > > +#include <linux/i2c.h>
> > > +#include <linux/input.h>
> > > +#include <linux/input/mt.h>
> > > +#include <linux/input/touchscreen.h>
> > > +#include <linux/interrupt.h>
> > > +#include <linux/kernel.h>
> > > +#include <linux/module.h>
> >
> > Please explicitly #include of_device.h.
> >
>
> Ack, thanks!
>
> > > +#include <linux/regulator/consumer.h>
> > > +
> > > +#define HX852X_COORD_SIZE(fingers) ((fingers) * sizeof(struct hx852x_coord))
> > > +#define HX852X_WIDTH_SIZE(fingers) ALIGN(fingers, 4)
> > > +#define HX852X_BUF_SIZE(fingers) (HX852X_COORD_SIZE(fingers) + \
> > > + HX852X_WIDTH_SIZE(fingers) + \
> > > + sizeof(struct hx852x_touch_info))
> > > +
> > > +#define HX852X_MAX_FINGERS 12
> >
> > Well, that's a new one :)
> >
>
> FWIW: I'm not sure if any controller exists that actually supports 12,
> but the bits are layed out in a way that it would be possible. :-)
>
> > > +#define HX852X_MAX_KEY_COUNT 4
> > > +#define HX852X_MAX_BUF_SIZE HX852X_BUF_SIZE(HX852X_MAX_FINGERS)
> > > +
> > > +#define HX852X_TS_SLEEP_IN 0x80
> > > +#define HX852X_TS_SLEEP_OUT 0x81
> > > +#define HX852X_TS_SENSE_OFF 0x82
> > > +#define HX852X_TS_SENSE_ON 0x83
> > > +#define HX852X_READ_ONE_EVENT 0x85
> > > +#define HX852X_READ_ALL_EVENTS 0x86
> > > +#define HX852X_READ_LATEST_EVENT 0x87
> > > +#define HX852X_CLEAR_EVENT_STACK 0x88
> > > +
> > > +#define HX852X_REG_SRAM_SWITCH 0x8c
> > > +#define HX852X_REG_SRAM_ADDR 0x8b
> > > +#define HX852X_REG_FLASH_RPLACE 0x5a
> > > +
> > > +#define HX852X_SRAM_SWITCH_TEST_MODE 0x14
> > > +#define HX852X_SRAM_ADDR_CONFIG 0x7000
> > > +
> > > +struct hx852x {
> > > + struct i2c_client *client;
> > > + struct input_dev *input_dev;
> > > + struct touchscreen_properties props;
> > > +
> > > + struct gpio_desc *reset_gpiod;
> > > + struct regulator_bulk_data supplies[2];
> > > +
> > > + unsigned int max_fingers;
> > > + unsigned int keycount;
> > > + u32 keycodes[HX852X_MAX_KEY_COUNT];
> >
> > Nit: might as well make keycodes 'unsigned int' for consistency; I also do not
> > feel the newlines are necessary.
> >
>
> I don't mind having the newlines but also don't mind removing them,
> will drop them in v2!
>
> > > +};
> > > +
> > > +struct hx852x_config {
> > > + u8 rx_num;
> > > + u8 tx_num;
> > > + u8 max_pt;
> > > + u8 padding1[3];
> > > + __be16 x_res;
> > > + __be16 y_res;
> > > + u8 padding2[2];
> > > +} __packed __aligned(4);
> >
> > What is the reason to include trailing padding in this packed struct? Does the
> > controller require the entire register length to be read for some reason?
> >
>
> Given your question I guess "padding" might be the wrong word here.
> Basically the driver we based this on reads this config in a
> semi-obfuscated way like this:
>
> char data[12];
> i2c_himax_read(..., data, 12, ...);
> rx_num = data[0];
> /* ... */
> x_res = data[6]*256 + data[7];
> /* ... */
>
> data[10] and data[11] are not used in the vendor code, so we don't know
> what is encoded there, if there is something encoded there, if only on
> some models or only on some firmware versions.
>
> I would prefer to keep the read/write operations similar to the vendor
> driver. Who knows if there are peculiar firmware versions that would
> fail if the read size is not correct. And maybe there is actually
> interesting data in there?
>
> Maybe "unknown" would be more clear than "padding"?
If it is unknown whether a specific number of bytes must be read from the
controller for it to remain in a valid state, then I think it is fine to
keep your existing implementation, as well as the original name 'padding'.
>
> > > +
> > > +struct hx852x_coord {
> > > + __be16 x;
> > > + __be16 y;
> > > +} __packed __aligned(4);
> > > +
> > > +struct hx852x_touch_info {
> > > + u8 finger_num;
> > > + __le16 finger_pressed;
> >
> > It's interesting that most registers/packets use big endian (e.g. x_res) while
> > only this uses little endian. Is that expected?
> >
>
> Yes, it's really like that. If you look closely the __le16 is also the
> only 16-bit number that isn't aligned properly. I guess for the
> "protocol designers" this fields was maybe not a 16-bit number but two
> separate fields. No idea what they were thinking.
ACK.
>
> > > + u8 padding;
> >
> > Same question with regard to trailing padding.
> >
>
> I think the same answer as above applies here. Additionally here, the
> packet format seems to be intentionally 4-byte/32-bit aligned (see
> comment in hx852x_handle_events()) so I would say it makes sense to also
> read an aligned size from the controller.
>
> > > +} __packed __aligned(4);
> > > +
> > > +static int hx852x_i2c_read(struct hx852x *hx, u8 cmd, void *data, u16 len)
> > > +{
> > > + struct i2c_client *client = hx->client;
> > > + int ret;
> > > +
> > > + struct i2c_msg msg[] = {
> > > + {
> > > + .addr = client->addr,
> > > + .flags = 0,
> > > + .len = 1,
> > > + .buf = &cmd,
> > > + },
> > > + {
> > > + .addr = client->addr,
> > > + .flags = I2C_M_RD,
> > > + .len = len,
> > > + .buf = data,
> > > + }
> > > + };
> > > +
> > > + ret = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg));
> > > + if (ret != ARRAY_SIZE(msg)) {
> > > + dev_err(&client->dev, "failed to read %#x: %d\n", cmd, ret);
> > > + return ret;
> > > + }
> > > +
> > > + return 0;
> > > +}
> >
> > This function does not appear to be doing anything unique (e.g. retry loop to
> > deal with special HW condition, etc.), so I do not see any reason to open-code
> > a standard write-then-read operation.
> >
> > Can i2c_smbus API simply replace this function,
>
> As far as I know the SMBus standard and API is limited to reading a
> maximum of 32 bytes (I2C_SMBUS_BLOCK_MAX). With >= 6 fingers the touch
> packet sizes will exceed that.
>
> > or better yet, can this driver
> > simply use regmap? In fact, that is what the other mainline Himax driver uses.
>
> Regmap could maybe work, but I think it does not really fit. The I2C
> interface here does not provide a consistent register map. Problem is,
> for regmap_config we would need to define "reg_bits" and "val_bits".
> This does not really exist here: The commands are usually sent without
> any arguments, sometimes with a single byte (HX852X_REG_SRAM_SWITCH) and
> sometimes with a word (HX852X_REG_SRAM_ADDR). There isn't a specific
> register set with values here but more like random "commands".
>
> Since SMBus doesn't allow reading more than 32 bytes and regmap does not
> fit I think this custom but fairly standard routine is necessary. :/
That makes sense; thank you for the follow-up.
>
> >
> > > +
> > > +static int hx852x_power_on(struct hx852x *hx)
> > > +{
> > > + struct device *dev = &hx->client->dev;
> > > + int error;
> > > +
> > > + error = regulator_bulk_enable(ARRAY_SIZE(hx->supplies), hx->supplies);
> > > + if (error < 0) {
> >
> > Nit: if (error) as you have done elsewhere.
> >
>
> Thanks, will fix this.
>
> > > + dev_err(dev, "failed to enable regulators: %d\n", error);
> > > + return error;
> > > + }
> > > +
> > > + gpiod_set_value_cansleep(hx->reset_gpiod, 1);
> > > + msleep(20);
> > > + gpiod_set_value_cansleep(hx->reset_gpiod, 0);
> > > + msleep(20);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int hx852x_start(struct hx852x *hx)
> > > +{
> > > + struct device *dev = &hx->client->dev;
> > > + int error;
> > > +
> > > + error = i2c_smbus_write_byte(hx->client, HX852X_TS_SLEEP_OUT);
> > > + if (error) {
> > > + dev_err(dev, "failed to send TS_SLEEP_OUT: %d\n", error);
> > > + return error;
> > > + }
> > > + msleep(30);
> > > +
> > > + error = i2c_smbus_write_byte(hx->client, HX852X_TS_SENSE_ON);
> > > + if (error) {
> > > + dev_err(dev, "failed to send TS_SENSE_ON: %d\n", error);
> > > + return error;
> > > + }
> > > + msleep(20);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static void hx852x_stop(struct hx852x *hx)
> > > +{
> > > + struct device *dev = &hx->client->dev;
> > > + int error;
> > > +
> > > + error = i2c_smbus_write_byte(hx->client, HX852X_TS_SENSE_OFF);
> > > + if (error)
> > > + dev_err(dev, "failed to send TS_SENSE_OFF: %d\n", error);
> >
> > Granted the function is of void type, should we not still return if there
> > is an error?
> >
> > Actually, I would still keep this function as an int for future re-use, even
> > though hx852x_input_close() simply ignores the value. This way, the return
> > value can be propagated to the return value of hx852x_suspend() and elsewhere.
> >
> > > +
> > > + msleep(20);
> > > +
> > > + error = i2c_smbus_write_byte(hx->client, HX852X_TS_SLEEP_IN);
> > > + if (error)
> > > + dev_err(dev, "failed to send TS_SLEEP_IN: %d\n", error);
> >
> > Same here; no need to sleep following a register write that seemingly did
> > not happen.
> >
> > > +
> > > + msleep(30);
> > > +}
> > > +
> > > +static void hx852x_power_off(struct hx852x *hx)
> > > +{
> > > + struct device *dev = &hx->client->dev;
> > > + int error;
> > > +
> > > + error = regulator_bulk_disable(ARRAY_SIZE(hx->supplies), hx->supplies);
> > > + if (error)
> > > + dev_err(dev, "failed to disable regulators: %d\n", error);
> > > +}
> >
> > Same comment with regard to function type; it's nice for internal helpers
> > to be of type int, even if the core callback using it is void.
> >
> > > +
> > > +static int hx852x_read_config(struct hx852x *hx)
> > > +{
> > > + struct device *dev = &hx->client->dev;
> > > + struct hx852x_config conf = {0};
> >
> > No need to initialize.
> >
> > > + int x_res, y_res;
> > > + int error;
> > > +
> > > + error = hx852x_power_on(hx);
> > > + if (error)
> > > + return error;
> > > +
> > > + /* Sensing must be turned on briefly to load the config */
> > > + error = hx852x_start(hx);
> > > + if (error)
> > > + goto power_off;
> > > +
> > > + hx852x_stop(hx);
> >
> > See my earlier comment about promoting this function's type to int.
> >
> > > +
> > > + error = i2c_smbus_write_byte_data(hx->client, HX852X_REG_SRAM_SWITCH,
> > > + HX852X_SRAM_SWITCH_TEST_MODE);
> > > + if (error)
> > > + goto power_off;
> > > +
> > > + error = i2c_smbus_write_word_data(hx->client, HX852X_REG_SRAM_ADDR,
> > > + HX852X_SRAM_ADDR_CONFIG);
> > > + if (error)
> > > + goto exit_test_mode;
> > > +
> > > + error = hx852x_i2c_read(hx, HX852X_REG_FLASH_RPLACE, &conf, sizeof(conf));
> > > + if (error)
> > > + goto exit_test_mode;
> > > +
> > > + x_res = be16_to_cpu(conf.x_res);
> > > + y_res = be16_to_cpu(conf.y_res);
> > > + hx->max_fingers = (conf.max_pt & 0xf0) >> 4;
> > > + dev_dbg(dev, "x res: %d, y res: %d, max fingers: %d\n",
> > > + x_res, y_res, hx->max_fingers);
> > > +
> > > + if (hx->max_fingers > HX852X_MAX_FINGERS) {
> > > + dev_err(dev, "max supported fingers: %d, found: %d\n",
> > > + HX852X_MAX_FINGERS, hx->max_fingers);
> > > + error = -EINVAL;
> > > + goto exit_test_mode;
> > > + }
> > > +
> > > + if (x_res && y_res) {
> > > + input_set_abs_params(hx->input_dev, ABS_MT_POSITION_X, 0, x_res - 1, 0, 0);
> > > + input_set_abs_params(hx->input_dev, ABS_MT_POSITION_Y, 0, y_res - 1, 0, 0);
> > > + }
> > > +
> > > +exit_test_mode:
> > > + i2c_smbus_write_byte_data(hx->client, HX852X_REG_SRAM_SWITCH, 0);
> >
> > Nit: it would still be nice to preserve as many return values as possible, perhaps
> > as follows:
> >
> > +exit_test_mode:
> > error = i2c_smbus_write_byte_data(...) ? : error;
> >
> > > +power_off:
> > > + hx852x_power_off(hx);
> > > + return error;
> >
> > Similarly, with hx852x_power_off() being promoted to int as suggested above,
> > this could be:
> >
> > return hx852x_power_off(...) ? : error;
> >
> > There are other idiomatic ways to do the same thing based on your preference.
> > Another (perhaps more clear) option would be to move some of these test mode
> > functions into a helper, which would also avoid some goto statements.
> >
>
> Thanks for your suggestions regarding the error handling / return codes.
> For v2 I will play with the different options you gave and look which
> one feels best. :-)
>
> > > +}
> > > +
> > > +static int hx852x_handle_events(struct hx852x *hx)
> > > +{
> > > + /*
> > > + * The event packets have variable size, depending on the amount of
> > > + * supported fingers (hx->max_fingers). They are laid out as follows:
> > > + * - struct hx852x_coord[hx->max_fingers]: Coordinates for each finger
> > > + * - u8[ALIGN(hx->max_fingers, 4)]: Touch width for each finger
> > > + * with padding for 32-bit alignment
> > > + * - struct hx852x_touch_info
> > > + *
> > > + * Load everything into a 32-bit aligned buffer so the coordinates
> > > + * can be assigned directly, without using get_unaligned_*().
> > > + */
> > > + u8 buf[HX852X_MAX_BUF_SIZE] __aligned(4);
> > > + struct hx852x_coord *coord = (struct hx852x_coord *)buf;
> > > + u8 *width = &buf[HX852X_COORD_SIZE(hx->max_fingers)];
> > > + struct hx852x_touch_info *info = (struct hx852x_touch_info *)
> > > + &width[HX852X_WIDTH_SIZE(hx->max_fingers)];
> > > + unsigned long finger_pressed, key_pressed;
> >
> > It seems these only need to be u16.
> >
>
> Right. However, unsigned long is necessary for using it with
> for_each_set_bit(), which wants a pointer to an unsigned long.
> I can change it for key_pressed though.
Thanks for the clarification; the existing implementation seems fine then.
>
> > > + unsigned int i, x, y, w;
> > > + int error;
> > > +
> > > + error = hx852x_i2c_read(hx, HX852X_READ_ALL_EVENTS, buf,
> > > + HX852X_BUF_SIZE(hx->max_fingers));
> > > + if (error)
> > > + return error;
> > > +
> > > + finger_pressed = get_unaligned_le16(&info->finger_pressed);
> > > + key_pressed = finger_pressed >> HX852X_MAX_FINGERS;
> > > +
> > > + /* All bits are set when no touch is detected */
> > > + if (info->finger_num == 0xff || !(info->finger_num & 0x0f))
> > > + finger_pressed = 0;
> > > + if (key_pressed == 0xf)
> > > + key_pressed = 0;
> > > +
> > > + for_each_set_bit(i, &finger_pressed, hx->max_fingers) {
> > > + x = be16_to_cpu(coord[i].x);
> > > + y = be16_to_cpu(coord[i].y);
> > > + w = width[i];
> > > +
> > > + input_mt_slot(hx->input_dev, i);
> > > + input_mt_report_slot_state(hx->input_dev, MT_TOOL_FINGER, 1);
> > > + touchscreen_report_pos(hx->input_dev, &hx->props, x, y, true);
> > > + input_report_abs(hx->input_dev, ABS_MT_TOUCH_MAJOR, w);
> > > + }
> > > + input_mt_sync_frame(hx->input_dev);
> > > +
> > > + for (i = 0; i < hx->keycount; i++)
> > > + input_report_key(hx->input_dev, hx->keycodes[i], key_pressed & BIT(i));
> > > +
> > > + input_sync(hx->input_dev);
> > > + return 0;
> > > +}
> > > +
> > > +static irqreturn_t hx852x_interrupt(int irq, void *ptr)
> > > +{
> > > + struct hx852x *hx = ptr;
> > > + int error;
> > > +
> > > + error = hx852x_handle_events(hx);
> > > + if (error) {
> > > + dev_err(&hx->client->dev, "failed to handle events: %d\n", error);
> > > + return IRQ_NONE;
> > > + }
> > > +
> > > + return IRQ_HANDLED;
> > > +}
> > > +
> > > +static int hx852x_input_open(struct input_dev *dev)
> > > +{
> > > + struct hx852x *hx = input_get_drvdata(dev);
> > > + int error;
> > > +
> > > + error = hx852x_power_on(hx);
> > > + if (error)
> > > + return error;
> > > +
> > > + error = hx852x_start(hx);
> > > + if (error) {
> > > + hx852x_power_off(hx);
> > > + return error;
> > > + }
> > > +
> > > + enable_irq(hx->client->irq);
> > > + return 0;
> > > +}
> > > +
> > > +static void hx852x_input_close(struct input_dev *dev)
> > > +{
> > > + struct hx852x *hx = input_get_drvdata(dev);
> > > +
> > > + hx852x_stop(hx);
> > > + disable_irq(hx->client->irq);
> > > + hx852x_power_off(hx);
> > > +}
> > > +
> > > +static int hx852x_parse_properties(struct hx852x *hx)
> > > +{
> > > + struct device *dev = &hx->client->dev;
> > > + int error;
> > > +
> > > + hx->keycount = device_property_count_u32(dev, "linux,keycodes");
> > > + if (hx->keycount <= 0) {
> > > + hx->keycount = 0;
> > > + return 0;
> > > + }
> > > +
> > > + if (hx->keycount > HX852X_MAX_KEY_COUNT) {
> > > + dev_err(dev, "max supported keys: %d, found: %d\n",
> >
> > Nit: these should both be printed as %u.
> >
>
> Right, thanks!
>
> > > + HX852X_MAX_KEY_COUNT, hx->keycount);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + error = device_property_read_u32_array(dev, "linux,keycodes",
> > > + hx->keycodes, hx->keycount);
> > > + if (error)
> > > + dev_err(dev, "failed to read linux,keycodes: %d\n", error);
> > > +
> > > + return error;
> > > +}
> > > +
> > > +static int hx852x_probe(struct i2c_client *client)
> > > +{
> > > + struct device *dev = &client->dev;
> > > + struct hx852x *hx;
> > > + int error, i;
> > > +
> > > + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C |
> > > + I2C_FUNC_SMBUS_WRITE_BYTE |
> > > + I2C_FUNC_SMBUS_WRITE_BYTE_DATA |
> > > + I2C_FUNC_SMBUS_WRITE_WORD_DATA)) {
> > > + dev_err(dev, "not all i2c functionality supported\n");
> > > + return -ENXIO;
> > > + }
> > > +
> > > + hx = devm_kzalloc(dev, sizeof(*hx), GFP_KERNEL);
> > > + if (!hx)
> > > + return -ENOMEM;
> > > +
> > > + hx->client = client;
> > > + hx->input_dev = devm_input_allocate_device(dev);
> > > + if (!hx->input_dev)
> > > + return -ENOMEM;
> > > +
> > > + hx->input_dev->name = "Himax HX852x";
> > > + hx->input_dev->id.bustype = BUS_I2C;
> > > + hx->input_dev->open = hx852x_input_open;
> > > + hx->input_dev->close = hx852x_input_close;
> > > +
> > > + i2c_set_clientdata(client, hx);
> > > + input_set_drvdata(hx->input_dev, hx);
> > > +
> > > + hx->supplies[0].supply = "vcca";
> > > + hx->supplies[1].supply = "vccd";
> > > + error = devm_regulator_bulk_get(dev, ARRAY_SIZE(hx->supplies), hx->supplies);
> > > + if (error < 0)
> > > + return dev_err_probe(dev, error, "failed to get regulators");
> > > +
> > > + hx->reset_gpiod = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> > > + if (IS_ERR(hx->reset_gpiod))
> > > + return dev_err_probe(dev, error, "failed to get reset gpio");
> >
> > Can the reset GPIO be optional?
> >
>
> I'm afraid I have no idea if the controller needs this or not. Would it
> be better to keep it required until someone confirms otherwise or have
> it optional for the other way around?
If you have a datasheet handy, or your hardware provides a means for you to
test and confirm whether reset can be left out, I would make the reset GPIO
optional. Often times, these controllers are part of a module and reset may
be tied high locally as opposed to adding another signal to a flex cable.
If you have no way to confirm, I would keep it as required for now; it is not
too cumbersome to be changed later if the need arises on different hardware.
>
> Thanks!
> Stephan
Kind regards,
Jeff LaBundy
