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
| ||
|
Message-ID: <Y385J2m5YByyAz0g@wendy> Date: Thu, 24 Nov 2022 09:28:07 +0000 From: Conor Dooley <conor.dooley@...rochip.com> To: Walker Chen <walker.chen@...rfivetech.com> CC: Emil Renner Berthing <emil.renner.berthing@...onical.com>, <linux-riscv@...ts.infradead.org>, <linux-pm@...r.kernel.org>, <devicetree@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, "Rafael J . Wysocki" <rafael@...nel.org>, <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v1 3/4] soc: starfive: Add StarFive JH71XX pmu driver Hey Walker, Just jumping in here... On Thu, Nov 24, 2022 at 05:08:57PM +0800, Walker Chen wrote: > On 2022/11/19 2:31, Emil Renner Berthing wrote: > > On Fri, 18 Nov 2022 at 14:35, Walker Chen <walker.chen@...rfivetech.com> wrote: > >> diff --git a/include/soc/starfive/pm_domains.h b/include/soc/starfive/pm_domains.h > >> new file mode 100644 > >> index 000000000000..a20e28e9baf3 > >> --- /dev/null > >> +++ b/include/soc/starfive/pm_domains.h > >> @@ -0,0 +1,15 @@ > >> +/* SPDX-License-Identifier: GPL-2.0 */ > >> +/* > >> + * Copyright (C) 2022 StarFive Technology Co., Ltd. > >> + * Author: Walker Chen <walker.chen@...rfivetech.com> > >> + */ > >> + > >> +#ifndef __SOC_STARFIVE_PMDOMAINS_H__ > >> +#define __SOC_STARFIVE_PMDOMAINS_H__ > >> + > >> +#include <linux/types.h> > >> + > >> +void starfive_pmu_hw_event_turn_on(u32 mask); > >> +void starfive_pmu_hw_event_turn_off(u32 mask); > >> + > >> +#endif /* __SOC_STARFIVE_PMDOMAINS_H__ */ > > > > The header and functions within are named very generic, but > > implemented by the jh71xx-specific driver. > > > > Also who should use this header? These functions are never called by > > anything in this series. > > These two functions will be used by the GPU module. Only the power-off > of the GPU is not controlled by the software through PMU module. So > here the functions are needed to export. ...the general policy is to avoid adding things without users. I think they should be kept as static functions for now & when your GPU driver is being upstreamed you can expose these functions. That way your usage of them can be reviewed with the appropriate context. Thanks, Conor.
Powered by blists - more mailing lists