lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABb+yY1Oy-vdXSQBQHoqzsK8xpXXfHw5ZQ5Q6gjv0gdFK2hwDA@mail.gmail.com>
Date: Mon, 4 Nov 2024 13:28:11 -0600
From: Jassi Brar <jassisinghbrar@...il.com>
To: Valentina.FernandezAlanis@...rochip.com
Cc: paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu, 
	peterlin@...estech.com, Conor.Dooley@...rochip.com, conor+dt@...nel.org, 
	ycliang@...estech.com, dminus@...estech.com, 
	prabhakar.mahadev-lad.rj@...renesas.com, robh@...nel.org, krzk+dt@...nel.org, 
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org
Subject: Re: [PATCH v2 3/3] mailbox: add Microchip IPC support

On Mon, Nov 4, 2024 at 1:01 PM <Valentina.FernandezAlanis@...rochip.com> wrote:
>
> On 03/11/2024 00:23, Jassi Brar wrote:

> 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.
>
Yes please avoid EXPORT at any cost. They are only acceptable when no
other means exist.

> >
> >> +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_*

OK.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ