Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i0ad843c9:Fastmail
Subject: Re: [PATCH v4 2/4] Input: pinephone-keyboard - Add PinePhone keyboard
 driver
To:     Andy Shevchenko <andy.shevchenko@gmail.com>
Cc:     Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        linux-input <linux-input@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Ondrej Jirman <x@xff.cz>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Chen-Yu Tsai <wens@csie.org>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
        linux-sunxi@lists.linux.dev
References: <20220618165747.55709-1-samuel@sholland.org>
 <20220618165747.55709-3-samuel@sholland.org>
 <CAHp75VcXNTxusT5N_8JvYWMhUyY_sAUzTcT3h0hz2bAawv6ThQ@mail.gmail.com>
From:   Samuel Holland <samuel@sholland.org>
Message-ID: <2e6499b8-d8f4-b63a-689b-1e93aca7c210@sholland.org>
Date:   Mon, 20 Jun 2022 23:12:46 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <CAHp75VcXNTxusT5N_8JvYWMhUyY_sAUzTcT3h0hz2bAawv6ThQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 6/19/22 6:43 AM, Andy Shevchenko wrote:
> On Sat, Jun 18, 2022 at 7:10 PM Samuel Holland <samuel@sholland.org> wrote:
>>
>> The official Pine64 PinePhone keyboard case contains a matrix keypad and
>> a MCU which runs a libre firmware. Add support for its I2C interface.
> 
> ...
> 
>> +#include <linux/crc8.h>
>> +#include <linux/i2c.h>
>> +#include <linux/input/matrix_keypad.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/module.h>
>> +#include <linux/regulator/consumer.h>
> 
> Missed
> types.h
> 
> ...
> 
>> +#define PPKB_ROWS                      6
>> +#define PPKB_COLS                      12
> 
> ...
> 
>> +       for (col = 0; col < PPKB_COLS; ++col) {
>> +               u8 old = old_buf[1 + col];
>> +               u8 new = new_buf[1 + col];
>> +               u8 changed = old ^ new;
>> +
>> +               if (!changed)
>> +                       continue;
>> +
>> +               for (row = 0; row < PPKB_ROWS; ++row) {
>> +                       u8 mask = BIT(row);
>> +                       u8 value = new & mask;
>> +                       unsigned short code;
>> +                       bool fn_state;
>> +
>> +                       if (!(changed & mask))
>> +                               continue;
>> +
>> +                       /*
>> +                        * Save off the FN key state when the key was pressed,
>> +                        * and use that to determine the code during a release.
>> +                        */
>> +                       fn_state = value ? ppkb->fn_pressed : ppkb->fn_state[col] & mask;
>> +                       if (fn_state)
>> +                               ppkb->fn_state[col] ^= mask;
> 
> Can't it be converted to use bitmap APIs?

This is a 2D matrix, with one byte per column, and one bit per row. There are
only 6 rows, so two bits per byte are unused. Converting this to the bitmap API
would unnecessarily complicate things.

>> +               }
>> +       }
> 
> ...
> 
>> +static int ppkb_set_scan(struct i2c_client *client, bool enable)
>> +{
>> +       struct device *dev = &client->dev;
>> +       int ret, val;
>> +
>> +       ret = i2c_smbus_read_byte_data(client, PPKB_SYS_CONFIG);
>> +       if (ret < 0) {
>> +               dev_err(dev, "Failed to read config: %d\n", ret);
>> +               return ret;
>> +       }
>> +
>> +       if (enable)
>> +               val = ret & ~PPKB_SYS_CONFIG_DISABLE_SCAN;
>> +       else
>> +               val = ret | PPKB_SYS_CONFIG_DISABLE_SCAN;
>> +       ret = i2c_smbus_write_byte_data(client, PPKB_SYS_CONFIG, val);
>> +       if (ret) {
>> +               dev_err(dev, "Failed to write config: %d\n", ret);
> 
>> +               return ret;
>> +       }
>> +
>> +       return 0;
> 
> return ret;

The "return 0" pattern is idiomatic, and more diff-friendly when adding error
handling or more operations. But I don't have that strong of an opinion on it.

Regards,
Samuel