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;
Date:   Mon, 1 Aug 2022 19:17:16 -0700
From:   Colin Foster <colin.foster@in-advantage.com>
To:     Andy Shevchenko <andy.shevchenko@gmail.com>
Cc:     linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        devicetree <devicetree@vger.kernel.org>,
        Terry Bowman <terry.bowman@amd.com>,
        Vladimir Oltean <vladimir.oltean@nxp.com>,
        Wolfram Sang <wsa@kernel.org>,
        Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
        Steen Hegelund <Steen.Hegelund@microchip.com>,
        Lars Povlsen <lars.povlsen@microchip.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Eric Dumazet <edumazet@google.com>,
        "David S. Miller" <davem@davemloft.net>,
        Russell King <linux@armlinux.org.uk>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Lee Jones <lee.jones@linaro.org>, katie.morris@in-advantage.com
Subject: Re: [PATCH v14 mfd 9/9] mfd: ocelot: add support for the vsc7512
 chip via spi
Message-ID: <YuiJLK8ncbHH3OhE@euler>
References: <20220722040609.91703-1-colin.foster@in-advantage.com>
 <20220722040609.91703-10-colin.foster@in-advantage.com>
 <CAHp75Ve-pqgb56punEL=p=PnEtjRnqTBSqgs+vVn1Zv8F94g9Q@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHp75Ve-pqgb56punEL=p=PnEtjRnqTBSqgs+vVn1Zv8F94g9Q@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?02E6em1qquWDLHx1I8zebBgWIJ71uPDQqUqdS6iOF2paisFuQ4DFaNtzdXVT?=
 =?us-ascii?Q?H/zM+cywPOYEriChdY2rGFyjC/0ABscJDfOXiH6zo4jU7tUUUlgQVOjN0E/1?=
 =?us-ascii?Q?12Ow5r7nMOttHikZzauExU0jM/J7P/xgrYgYoLSeu4wimd/mG1mIaR2l1fx2?=
 =?us-ascii?Q?VObpbB/jtUFXs/5DekGsjjiJjRiQ3LAYe3DD11KcX7Me8SBcouLSZMHClPeC?=
 =?us-ascii?Q?T7e0qw5b45M8BUWzk6lQzmp8o5xJHTR8GzdRMGk2UoXJJjYzTGVK4oS6PPEZ?=
 =?us-ascii?Q?GDeYoUKTisKyFOv8nR/KMB7eJhnJzELdiTFLohHbjX3Hdy0t5yZ4Dtsww1m+?=
 =?us-ascii?Q?9SUz5qee4QuSPdx9Jg2U8JU6WllY9RLErx72i3KTu8BFrGDvNWqPawZ7bJJc?=
 =?us-ascii?Q?bGMUsDVqEX03qyBAtIBey74UmCQ8LNDAbgXiSl9DA4JEqvcikRRDGTSKKuZj?=
 =?us-ascii?Q?f70qPLQaqOeIoO7ZnpfhXwMBVCTvCDHat44/xr13izfE2yRDgcsIZo4rB/33?=
 =?us-ascii?Q?mia/KSAOzc3UV5WNbyfzMQweBJ8c8FhzJr5+cvdVRiqBupyy15Kc3T9hsdwA?=
 =?us-ascii?Q?BSvJLyusBp5dZv0MleLonw5DcISyOTuyDeEDzqJpzM0AXZa+CMxg2Vl2fIqn?=
 =?us-ascii?Q?tFpOqb88o4W6fPPI2RuxVtxHnZ2TCxwJHN8N36H5QfaYa4Hj98ocMZrNwbjl?=
 =?us-ascii?Q?CvFUD2bbZeLtafPnr1jXKe2tMTiLyXS79ML+FQiykrkpIgMbw2d+5lwTISgg?=
 =?us-ascii?Q?ZL+M0p6tsz4ZjP+RQhky4Z7BOzuS1xQrYD8tVdm3KY8jV/j9smPFxmeBmB8N?=
 =?us-ascii?Q?m9s73v2oE3nd5jpCsjA1yRvuTrp7hsDd9kexhnOsy3oPaWH3GsMe6ccgXBPz?=
 =?us-ascii?Q?jUtj/+jSvdwtkh0DHAeI8isf9oLkh/WNwM32XjLpHGeED0UY5XCuzOzrR3/m?=
 =?us-ascii?Q?yVtkG0lfkxcBpNJ/W4ytBj4hpTcD95CGUt3HaOypnOK8MwFr+CVkb6ZLkBOG?=
 =?us-ascii?Q?RKK1X1vH4VWC2T24M4qtr8cTecTwUotNAL3L28CMVpLFllFwXbTxkaa0FLh2?=
 =?us-ascii?Q?McU6HEmOWGryZItAKIzjg/gf/3Zh7zXB/24nyKN7XlKx9JoGjZ6aju1l8Dw0?=
 =?us-ascii?Q?npPq4aIrRz4/hX+1WcA3rALPUvxLTfzdxe5j+iOrEh9SdGUVyU9+yMHxCmRE?=
 =?us-ascii?Q?xeMtW9+7xkIhR53OXbJ32qiYP+PXU0DH8XVv2x54U3wbbFjHvCZ1A8xlPy6c?=
 =?us-ascii?Q?WQEnkJLVvizS5jgxFzTNNl7ccrGmts2IpD3HtbIYv9Brmsy2mC+W95f8ilRQ?=
 =?us-ascii?Q?oNB6A8xEuHkE0oU27w9SjljD2/ahLcne06r7nvcaAyZEMHY8eGiKcKVgsDuO?=
 =?us-ascii?Q?YKfH4Nbwz53gmNuPGL5zTkWUQN8D1CZBzOmczY0UcGBgq4Y4BmMkMqL11K81?=
 =?us-ascii?Q?tZw7DldN3or38Q1QUo6L2MjzFMnO9w/y0XqMQraxBNbky6Bgn3cYbrMwYGkW?=
 =?us-ascii?Q?H/sX5Syx35vkJShGCvHWW8hZdNG6n3vIQapHLi5mdNgQ9815Q9IbOW2KAhvH?=
 =?us-ascii?Q?kT8lViP6ckPvEYQwyOCxkiQ1eP4POQ7DSAWM8O5cx9UPy68M63f49rDdzHEL?=
 =?us-ascii?Q?nw=3D=3D?=
X-OriginatorOrg: in-advantage.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 78e75a64-5c80-49e4-5e82-08da742d2135
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2351.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2022 02:17:21.0842
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 48e842ca-fbd8-4633-a79d-0c955a7d3aae
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: pbrRDsrESAEjM8ofpt3L1PvpNd0f0Fzwhx9lxL4uZHDNJD6z+W/utVtb4JseaYA9tgXVIY7N/DZ/9h10VAJIFtzSENfBuaQY4S3Mm0cfFV0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR10MB5585
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Andy,

Apologies for the late response. Everything seemed straightforward, but
as I was implementing your suggestions one thing came out.

I just want to make sure my implementation isn't horribly off before the
next patch set.

Specifically this question (copied from below):
> I'm wondering if you can use in both cases
> spi_message_init_with_transfers().

> > +static int ocelot_spi_regmap_bus_read(void *context, const void *reg, size_t reg_size,
> > +                                     void *val, size_t val_size)
> > +{
> > +       struct spi_transfer tx, padding, rx;

struct spi_transfer xfers[3] = {0};
struct spi_transfer *xfer_tok = xfers;

> > +       struct device *dev = context;
> > +       struct ocelot_ddata *ddata;
> > +       struct spi_device *spi;
> > +       struct spi_message msg;
> > +
> > +       ddata = dev_get_drvdata(dev);
> > +       spi = to_spi_device(dev);
> > +
> > +       spi_message_init(&msg);
> > +
> > +       memset(&tx, 0, sizeof(tx));
> > +
> > +       tx.tx_buf = reg;
> > +       tx.len = reg_size;

xfer_tok->tx_buf = reg;
xfer_tok->len = reg_size;
xfer_tok++;

> > +
> > +       spi_message_add_tail(&tx, &msg);
> > +
> > +       if (ddata->spi_padding_bytes) {
> > +               memset(&padding, 0, sizeof(padding));
> > +
> > +               padding.len = ddata->spi_padding_bytes;
> > +               padding.tx_buf = ddata->dummy_buf;
> > +               padding.dummy_data = 1;

xfer_tok->len
xfer_tok->tx_buf
xfer_tok->dummy_data
xfer_tok++;

> > +
> > +               spi_message_add_tail(&padding, &msg);
> > +       }
> > +
> > +       memset(&rx, 0, sizeof(rx));
> > +       rx.rx_buf = val;
> > +       rx.len = val_size;

xfer_tok->rx_buf
xfer_tok->len
xfer_tok++;

> > +
> > +       spi_message_add_tail(&rx, &msg);

spi_message_init_with_transfers(&msg, xfers, xfer_tok - xfers);

> 
> I'm wondering if you can use in both cases
> spi_message_init_with_transfers().

I could see that implementation getting the response of "what the heck
were you thinking" or "that looks alright" and I honestly have no idea
which pool it will fall into.

> 
> > +       return spi_sync(spi, &msg);
> > +}
>