Re: drivers/pnp/pnpacpi/core.c:253:17: warning: 'strncpy' specified bound 50 equals destination size

[Sudeep Holla <sudeep.holla@arm.com>]

On Wed, Jul 26, 2023 at 03:05:15PM +0100, Suzuki K Poulose wrote:
> On 25/07/2023 15:30, Rafael J. Wysocki wrote:
> > On Tue, Jul 25, 2023 at 4:040x202FPM Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> >>
> >> On 25/07/2023 15:00, Rafael J. Wysocki wrote:
> >>> On Tue, Jul 25, 2023 at 3:270x202FPM Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> >>>>
> >>>> On 25/07/2023 13:28, Rafael J. Wysocki wrote:
> >>>>> On Tue, Jul 25, 2023 at 12:350x202FPM Suzuki K Poulose
> >>>>> <suzuki.poulose@arm.com> wrote:
> >>>>>>
> >>>>>> Hi Rafael
> >>>>>>
> >>>>>> Apologies for hijacking this thread, but please please could
> >>>>>> you respond to the following patch ?
> >>>>>>
> >>>>>> We have been waiting for your Ack since last two months.
> >>>>>>
> >>>>>> https://lkml.kernel.org/r/46a3d6d3-f14e-efde-83eb-5952f313f909@arm.com
> >>>>>
> >>>>> Sorry about that, but I'm not sure why you need an ACK from me for
> >>>>> this.0x00A0 AMBA is an ARM thing and I'm not even familiar with the driver
> >>>>> in question.
> >>>>>
> >>>>
> >>>> I understand, but there is a change to the drivers/acpi/acpi_amba.c ,
> >>>> which is technically under your maintenance. The change is removing
> >>>> the custom hook for the ETMv4 ID from the AMBA list and moving it
> >>>> directly under the ETMv4 driver. Greg would like an Ack from you
> >>>> before that can be queued. It missed the merged window last time
> >>>> due to that and didn't want to miss it again this time.
> >>>
> >>> OK, so please feel free to add an ACK from me to that patch.
> >>>
> >>
> >> Thanks.
> >>
> >>> It also would be good to find an ARM maintainer for acpi_amba.c, so
> >>> people don't have to wait for my ACK on every change in that file.
> >>
> >> Sudeep Holla (our resident ACPI expert) has reviewed the patch, but
> >> I guess he is in the Reviewer ranks.
> >
> > Well, next time you get a Reviewed-by from Sudeep on ARM-related ACPI
> > material, it is far more meaningful than my ACK.0x00A0 You probably don't
> > need the latter if you have the former.

Thanks Rafael and this aligns with my understanding. I had mentioned to
Suzuki informally. Since I wasn't sure why this was not covered under
Arm ACPI maintainership for whatever historical reasons, I didn't make
it formally on the list. I think it would be better if we move that file
under it to be explicit and avoid any confusion in the future. I will
send the update soon.

-- 
Regards,
Sudeep