drivers/remoteproc/xlnx_r5_remoteproc.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Bindings can be deprecated and driver should not include bindings
headers directly. Instead define needed constants in the driver.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
---
drivers/remoteproc/xlnx_r5_remoteproc.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
index 45a62cb98072..f5b736fa3cb4 100644
--- a/drivers/remoteproc/xlnx_r5_remoteproc.c
+++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
@@ -4,7 +4,6 @@
*
*/
-#include <dt-bindings/power/xlnx-zynqmp-power.h>
#include <linux/dma-mapping.h>
#include <linux/firmware/xlnx-zynqmp.h>
#include <linux/kernel.h>
@@ -19,6 +18,11 @@
#include "remoteproc_internal.h"
+#define PD_R5_0_ATCM 15
+#define PD_R5_0_BTCM 16
+#define PD_R5_1_ATCM 17
+#define PD_R5_1_BTCM 18
+
/* IPI buffer MAX length */
#define IPI_BUF_LEN_MAX 32U
base-commit: 54dacf6efe7196c1cd8ae4b5c691579d0510a8bd
--
2.34.1
On Fri, May 08, 2026 at 10:40:06AM -0700, Tanmay Shah wrote: > Bindings can be deprecated and driver should not include bindings > headers directly. Instead define needed constants in the driver. > Is there an official directive about not including bindings in drivers? To me it seems advantageous to have a focal point for the definition of constants, guaranteeing eveyone uses the same values. > Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> > --- > drivers/remoteproc/xlnx_r5_remoteproc.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c > index 45a62cb98072..f5b736fa3cb4 100644 > --- a/drivers/remoteproc/xlnx_r5_remoteproc.c > +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c > @@ -4,7 +4,6 @@ > * > */ > > -#include <dt-bindings/power/xlnx-zynqmp-power.h> > #include <linux/dma-mapping.h> > #include <linux/firmware/xlnx-zynqmp.h> > #include <linux/kernel.h> > @@ -19,6 +18,11 @@ > > #include "remoteproc_internal.h" > > +#define PD_R5_0_ATCM 15 > +#define PD_R5_0_BTCM 16 > +#define PD_R5_1_ATCM 17 > +#define PD_R5_1_BTCM 18 > + > /* IPI buffer MAX length */ > #define IPI_BUF_LEN_MAX 32U > > > base-commit: 54dacf6efe7196c1cd8ae4b5c691579d0510a8bd > -- > 2.34.1 >
On 5/26/2026 9:48 AM, Mathieu Poirier wrote: > On Fri, May 08, 2026 at 10:40:06AM -0700, Tanmay Shah wrote: >> Bindings can be deprecated and driver should not include bindings >> headers directly. Instead define needed constants in the driver. >> > > Is there an official directive about not including bindings in drivers? To me > it seems advantageous to have a focal point for the definition of constants, > guaranteeing eveyone uses the same values. > This is what I found from here: https://docs.kernel.org/process/maintainer-soc.html 2.3.2. Driver Branch Dependencies "Avoid defining custom macros in include/dt-bindings/ for hardware constants that can be derived from a datasheet -- binding macros in header files should only be used as a last resort if there is no natural way to define a binding" Also, bindings can be deprecated, so if the current binding gets deprecated, the header file can be removed from the include/dt-bindings. >> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> >> --- >> drivers/remoteproc/xlnx_r5_remoteproc.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c >> index 45a62cb98072..f5b736fa3cb4 100644 >> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c >> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c >> @@ -4,7 +4,6 @@ >> * >> */ >> >> -#include <dt-bindings/power/xlnx-zynqmp-power.h> >> #include <linux/dma-mapping.h> >> #include <linux/firmware/xlnx-zynqmp.h> >> #include <linux/kernel.h> >> @@ -19,6 +18,11 @@ >> >> #include "remoteproc_internal.h" >> >> +#define PD_R5_0_ATCM 15 >> +#define PD_R5_0_BTCM 16 >> +#define PD_R5_1_ATCM 17 >> +#define PD_R5_1_BTCM 18 >> + >> /* IPI buffer MAX length */ >> #define IPI_BUF_LEN_MAX 32U >> >> >> base-commit: 54dacf6efe7196c1cd8ae4b5c691579d0510a8bd >> -- >> 2.34.1 >>
On Tue, 26 May 2026 at 10:27, Shah, Tanmay <tanmays@amd.com> wrote: > > > > On 5/26/2026 9:48 AM, Mathieu Poirier wrote: > > On Fri, May 08, 2026 at 10:40:06AM -0700, Tanmay Shah wrote: > >> Bindings can be deprecated and driver should not include bindings > >> headers directly. Instead define needed constants in the driver. > >> > > > > Is there an official directive about not including bindings in drivers? To me > > it seems advantageous to have a focal point for the definition of constants, > > guaranteeing eveyone uses the same values. > > > > This is what I found from here: > https://docs.kernel.org/process/maintainer-soc.html > > 2.3.2. Driver Branch Dependencies > > "Avoid defining custom macros in include/dt-bindings/ for hardware > constants that can be derived from a datasheet -- binding macros in > header files should only be used as a last resort if there is no natural > way to define a binding" > > Also, bindings can be deprecated, so if the current binding gets > deprecated, the header file can be removed from the include/dt-bindings. > Fair enough. I'll apply your patch tomorrow. > >> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com> > >> --- > >> drivers/remoteproc/xlnx_r5_remoteproc.c | 6 +++++- > >> 1 file changed, 5 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c > >> index 45a62cb98072..f5b736fa3cb4 100644 > >> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c > >> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c > >> @@ -4,7 +4,6 @@ > >> * > >> */ > >> > >> -#include <dt-bindings/power/xlnx-zynqmp-power.h> > >> #include <linux/dma-mapping.h> > >> #include <linux/firmware/xlnx-zynqmp.h> > >> #include <linux/kernel.h> > >> @@ -19,6 +18,11 @@ > >> > >> #include "remoteproc_internal.h" > >> > >> +#define PD_R5_0_ATCM 15 > >> +#define PD_R5_0_BTCM 16 > >> +#define PD_R5_1_ATCM 17 > >> +#define PD_R5_1_BTCM 18 > >> + > >> /* IPI buffer MAX length */ > >> #define IPI_BUF_LEN_MAX 32U > >> > >> > >> base-commit: 54dacf6efe7196c1cd8ae4b5c691579d0510a8bd > >> -- > >> 2.34.1 > >> >
© 2016 - 2026 Red Hat, Inc.