devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <Valentina.FernandezAlanis@microchip.com>
To: <jassisinghbrar@gmail.com>
Cc: <paul.walmsley@sifive.com>, <palmer@dabbelt.com>,
	<aou@eecs.berkeley.edu>, <peterlin@andestech.com>,
	<Conor.Dooley@microchip.com>, <conor+dt@kernel.org>,
	<ycliang@andestech.com>, <dminus@andestech.com>,
	<prabhakar.mahadev-lad.rj@bp.renesas.com>, <robh@kernel.org>,
	<krzk+dt@kernel.org>, <linux-riscv@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<Valentina.FernandezAlanis@microchip.com>
Subject: Re: [PATCH v2 3/3] mailbox: add Microchip IPC support
Date: Mon, 4 Nov 2024 19:01:05 +0000	[thread overview]
Message-ID: <ee8b10e3-ccd2-409e-82d0-612107f3fe26@microchip.com> (raw)
In-Reply-To: <CABb+yY3cDD-E-P1MPKQjdX7R2XVVKjwXUW-BANWcz-9aR6kskA@mail.gmail.com>

On 03/11/2024 00:23, Jassi Brar wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Fri, Oct 25, 2024 at 7:36 AM Valentina Fernandez
> <valentina.fernandezalanis@microchip.com> wrote:
> 
> ....
>> +
>> +enum ipc_irq_type {
>> +       IPC_OPS_NOT_SUPPORTED   = 1,
>> +       IPC_MP_IRQ              = 2,
>> +       IPC_MC_IRQ              = 4,
>> +};
> totally unused.
> 
>> +
>> +/**
>> + * struct mchp_ipc_probe - IPC probe message format
>> + *
>> + * @hw_type:           IPC implementation available in the hardware
>> + * @num_channels:      number of IPC channels available in the hardware
>> + *
>> + * Used to retrieve information on the IPC implementation
>> + * using the SBI_EXT_IPC_PROBE SBI function id.
>> + */
>> +struct mchp_ipc_probe {
>   same as the driver.probe(), so maybe call this microchip_mbox_info
> 
> ......
> 
>> +struct mchp_ipc_cluster_cfg {
>> +       void *buf_base;
>> +       unsigned long buf_base_addr;
>> +       int irq;
>> +};
>> +
>> +struct ipc_chan_info {
>   I suggest s/ipc_chan_info/microchip_sbi_chan and hooking it to
> mbox_chan.con_priv
> 
> ....
> 
>> +       unsigned long buf_base_tx_addr;
>> +       unsigned long buf_base_rx_addr;
>> +       unsigned long msg_buf_tx_addr;
>> +       unsigned long msg_buf_rx_addr;
> If these are __pa(), then phys_addr_t please.
> 
>> +       int chan_aggregated_irq;
>> +       int mp_irq;
>> +       int mc_irq;
>> +       u32 id;
>> +       u32 max_msg_size;
>> +};
>> +
>> +struct microchip_ipc {
>   Maybe s/microchip_ipc/microchip_sbi_mbox ?
> 
> 
>> +       struct device *dev;
>> +       struct mbox_chan *chans;
>> +       struct mchp_ipc_cluster_cfg *cluster_cfg;
>> +       struct ipc_chan_info *priv;
>    replace this with 'struct mbox_chan *chan' and hook
>       chan[i].con_priv = priv[i]
>    this will help avoid having to EXPORT mchp_ipc_get_chan_id

Thanks for the feedback, I'll implement the suggestions in v3.

Regarding the EXPORT function, I understand that it’s also possible to 
retrieve con_priv from mbox_chan in the client. However, I felt it would 
be cleaner to export the function to obtain the channel ID directly, 
rather than declaring the struct ipc_chan_info in a header file to make 
it accessible to the client.

If necessary, I can remove the function and instead expose struct 
ipc_chan_info in linux/mailbox/mchp-ipc.h.
> 
> 
>> +       void *buf_base;
>> +       unsigned long buf_base_addr;
> phys_addr_t buf_base_addr ?
> 
>> +       struct mbox_controller controller;
>> +       u8 num_channels;
> this could be dropped by directly using 'controller.num_chans'
> 
> ......
> 
>> +static int mchp_ipc_send_data(struct mbox_chan *chan, void *data)
>> +{
>> +       struct ipc_chan_info *chan_info = (struct ipc_chan_info *)chan->con_priv;
>> +       const struct mchp_ipc_msg *msg = data;
>> +       struct mchp_ipc_sbi_msg sbi_payload;
>> +
>> +       memcpy(chan_info->msg_buf_tx, msg->buf, msg->size);
>> +       sbi_payload.buf_addr = chan_info->msg_buf_tx_addr;
>> +       sbi_payload.size = msg->size;
>> +       memcpy(chan_info->buf_base_tx, &sbi_payload, sizeof(sbi_payload));
> How does this work? sizeof(sbi_payload) is more than
> sizeof(*chan_info->buf_base_tx)
> I think buf_base_tx needs to be u8 array of max{sizeof(struct
> mchp_ipc_init), sizeof(struct mchp_ipc_sbi_msg)}, if there are
> alignment requirements then maybe kmalloc that size.
> Similarly for buf_base_rx.
> 
> ...
> 
>> +static struct platform_driver mchp_ipc_driver = {
>> +       .driver = {
>> +               .name = "microchip_ipc",
>> +               .of_match_table = mchp_ipc_of_match,
>> +       },
>> +       .probe = mchp_ipc_probe,
> The driver could be built as a module, so please provide .remove()
> even if you never intend to unload it.
In this particular case, there is nothing specific to implement in the 
.remove() function because all resources allocated in the .probe() 
function are managed using devm_*
> 
> cheers.


  reply	other threads:[~2024-11-04 19:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25 12:51 [PATCH v2 0/3] Add Microchip IPC mailbox Valentina Fernandez
2024-10-25 12:51 ` [PATCH v2 1/3] riscv: sbi: vendorid_list: Add Microchip Technology to the vendor list Valentina Fernandez
2024-10-25 12:51 ` [PATCH v2 2/3] dt-bindings: mailbox: add binding for Microchip IPC mailbox controller Valentina Fernandez
2024-10-29 12:48   ` Rob Herring
2024-10-31 10:07     ` Valentina.FernandezAlanis
2024-10-25 12:51 ` [PATCH v2 3/3] mailbox: add Microchip IPC support Valentina Fernandez
2024-11-03  0:23   ` Jassi Brar
2024-11-04 19:01     ` Valentina.FernandezAlanis [this message]
2024-11-04 19:28       ` Jassi Brar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ee8b10e3-ccd2-409e-82d0-612107f3fe26@microchip.com \
    --to=valentina.fernandezalanis@microchip.com \
    --cc=Conor.Dooley@microchip.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dminus@andestech.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peterlin@andestech.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=robh@kernel.org \
    --cc=ycliang@andestech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).