Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <1594117856-14343-1-git-send-email-gene.chen.richtek@gmail.com>
 <1594117856-14343-4-git-send-email-gene.chen.richtek@gmail.com> <3205bb9b-c7b4-c99a-2673-f3a56cc0addf@gmail.com>
In-Reply-To: <3205bb9b-c7b4-c99a-2673-f3a56cc0addf@gmail.com>
From:   Gene Chen <gene.chen.richtek@gmail.com>
Date:   Thu, 16 Jul 2020 17:53:36 +0800
Message-ID: <CAE+NS36LOqnG+toSQcxVAeQHUqyvs9Z39tU7-ijkAntRUH6uqg@mail.gmail.com>
Subject: Re: [PATCH 3/4] mfd: mt6360: Fix flow which is used to check ic exist
To:     Matthias Brugger <matthias.bgg@gmail.com>
Cc:     Lee Jones <lee.jones@linaro.org>,
        linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
        Gene Chen <gene_chen@richtek.com>, shufan_lee@richtek.com,
        cy_huang@richtek.com, benjamin.chao@mediatek.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Matthias Brugger <matthias.bgg@gmail.com> =E6=96=BC 2020=E5=B9=B47=E6=9C=88=
10=E6=97=A5 =E9=80=B1=E4=BA=94 =E4=B8=8B=E5=8D=8810:25=E5=AF=AB=E9=81=93=EF=
=BC=9A
>
>
>
> On 07/07/2020 12:30, Gene Chen wrote:
> > From: Gene Chen <gene_chen@richtek.com>
> >
> > Fix flow which is used to check ic exist
> >
> > Signed-off-by: Gene Chen <gene_chen@richtek.com>
> > ---
> >   drivers/mfd/mt6360-core.c  | 28 +++++++++++++++++++---------
> >   include/linux/mfd/mt6360.h |  8 ++++----
> >   2 files changed, 23 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c
> > index 2dd5918..4bb2949 100644
> > --- a/drivers/mfd/mt6360-core.c
> > +++ b/drivers/mfd/mt6360-core.c
> > @@ -293,6 +293,23 @@ static const struct mfd_cell mt6360_devs[] =3D {
> >                   NULL, 0, 0, "mediatek,mt6360-tcpc"),
> >   };
> >
> > +static int mt6360_check_vendor_info(struct mt6360_data *data)
> > +{
> > +     u32 info;
> > +     int ret;
> > +
> > +     ret =3D regmap_read(data->regmap, MT6360_REG_PMU_DEVINFO, &info);
> > +     if (ret < 0)
> > +             return ret;
> > +
> > +     if ((info & MT6360_CHIPVEN_MASK) !=3D MT6360_CHIPVEN_VAL)
> > +             return -ENODEV;
> > +
> > +     data->chip_rev =3D info & MT6360_CHIPREV_MASK;
> > +
> > +     return 0;
> > +}
> > +
> >   static const unsigned short mt6360_slave_addr[MT6360_SLAVE_MAX] =3D {
> >       MT6360_PMU_SLAVEID,
> >       MT6360_PMIC_SLAVEID,
> > @@ -303,7 +320,6 @@ static const unsigned short mt6360_slave_addr[MT636=
0_SLAVE_MAX] =3D {
> >   static int mt6360_probe(struct i2c_client *client)
> >   {
> >       struct mt6360_data *data;
> > -     unsigned int reg_data;
> >       int i, ret;
> >
> >       data =3D devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
> > @@ -319,16 +335,10 @@ static int mt6360_probe(struct i2c_client *client=
)
> >               return PTR_ERR(data->regmap);
> >       }
> >
> > -     ret =3D regmap_read(data->regmap, MT6360_PMU_DEV_INFO, &reg_data)=
;
> > +     ret =3D mt6360_check_vendor_info(data);
> >       if (ret) {
> > -             dev_err(&client->dev, "Device not found\n");
> > -             return ret;
> > -     }
> > -
> > -     data->chip_rev =3D reg_data & CHIP_REV_MASK;
> > -     if (data->chip_rev !=3D CHIP_VEN_MT6360) {
>
> Why not only applying the MASK here instead of put this all in a new func=
tion?
>

I think merge the ic check flow into function is well-organized.
if not, i can restore the same as before.

> >               dev_err(&client->dev, "Device not supported\n");
> > -             return -ENODEV;
> > +             return ret;
> >       }
> >
> >       ret =3D devm_regmap_add_irq_chip(&client->dev, data->regmap, clie=
nt->irq,
> > diff --git a/include/linux/mfd/mt6360.h b/include/linux/mfd/mt6360.h
> > index 9fc6718..5ec0f5d 100644
> > --- a/include/linux/mfd/mt6360.h
> > +++ b/include/linux/mfd/mt6360.h
> > @@ -30,7 +30,7 @@ struct mt6360_data {
> >   };
> >
> >   /* PMU register defininition */
> > -#define MT6360_PMU_DEV_INFO                  (0x00)
> > +#define MT6360_REG_PMU_DEVINFO                       (0x00)
> >   #define MT6360_PMU_CORE_CTRL1                       (0x01)
> >   #define MT6360_PMU_RST1                             (0x02)
> >   #define MT6360_PMU_CRCEN                    (0x03)
> > @@ -233,8 +233,8 @@ struct mt6360_data {
> >   #define MT6360_IRQ_REGNUM   16
> >   #define MT6360_IRQ_RETRIG   BIT(2)
> >
> > -#define CHIP_VEN_MASK                                (0xF0)
> > -#define CHIP_VEN_MT6360                              (0x50)
> > -#define CHIP_REV_MASK                                (0x0F)
> > +#define MT6360_CHIPVEN_MASK                  (0xF0)
> > +#define MT6360_CHIPVEN_VAL                   (0x50)
> > +#define MT6360_CHIPREV_MASK                  (0x0F)
>
> Same here as in the other patches. Don't just rename defines if there is =
no good
> reason.
>

Is easy to read a good reason to rename it?
if not, i can restore the same as before.

> Regards,
> Matthias
>
> >
> >   #endif /* __MT6360_H__ */
> >