Date   

[PATCH/RFC 4.19.y-cip v2 03/51] pinctrl: sh-pfc: Add physical pin multiplexing helper macros

Fabrizio Castro <fabrizio.castro@...>
 

From: Ulrich Hecht <uli+renesas@...>

commit 50d1ba1764b3e00ae8c331202d50c5535d6b3361 upstream.

Used by I2C controllers 0, 3 and 5 in R8A7795 and R8A7796 SoCs.

Signed-off-by: Ulrich Hecht <uli+renesas@...>
Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
drivers/pinctrl/sh-pfc/sh_pfc.h | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
index 7f31300..8a06ebc 100644
--- a/drivers/pinctrl/sh-pfc/sh_pfc.h
+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -389,6 +389,28 @@ extern const struct sh_pfc_soc_info shx3_pinmux_info;
PINMUX_DATA(fn##_MARK, FN_##msel, FN_##fn, FN_##ipsr)

/*
+ * Describe a pinmux configuration similar to PINMUX_IPSR_MSEL, but with
+ * an additional select register that controls physical multiplexing
+ * with another pin.
+ * - ipsr: IPSR field
+ * - fn: Function name, also referring to the IPSR field
+ * - psel: Physical multiplexing selector
+ * - msel: Module selector
+ */
+#define PINMUX_IPSR_PHYS_MSEL(ipsr, fn, psel, msel) \
+ PINMUX_DATA(fn##_MARK, FN_##psel, FN_##msel, FN_##fn, FN_##ipsr)
+
+/*
+ * Describe a pinmux configuration in which a pin is physically multiplexed
+ * with other pins.
+ * - ipsr: IPSR field
+ * - fn: Function name, also referring to the IPSR field
+ * - psel: Physical multiplexing selector
+ */
+#define PINMUX_IPSR_PHYS(ipsr, fn, psel) \
+ PINMUX_DATA(fn##_MARK, FN_##psel)
+
+/*
* Describe a pinmux configuration for a single-function pin with GPIO
* capability.
* - fn: Function name
--
2.7.4


[PATCH/RFC 4.19.y-cip v2 02/51] pinctrl: sh-pfc: Validate pinmux tables at runtime when debugging

Fabrizio Castro <fabrizio.castro@...>
 

From: Geert Uytterhoeven <geert+renesas@...>

commit 6161b39a14380815f22851c753c00acf81cfa62a upstream.

Perform some basic sanity checks on all built-in pinmux tables when
DEBUG is defined, to help catching bugs early.

For now the following checks are included:
- Check register and field widths in descriptors for config registers
with variable-width fields,
- Check relations between pin groups and functions:
- All pin functions must refer to existing pin groups,
- All pin groups must be referred to by a pin function,
- Warn if a pin group is referred to by multiple pin functions
(which is OK for backwards-compatibility aliases),
- Provide suggestions for reducing table sizes: reserved fields of
more than 3 bits can better be split in smaller subfields, as the
storage need is proportional to the square of the width of the
(sub)field,

Note that a dummy non-matching entry is added to the DT match table for
checking r8a7795es1_pinmux_info, as R-Car H3 ES1.0 is matched using
soc_device_match() in r8a7795_pinmux_init(), instead of by the DT match
table.

Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Reviewed-by: Simon Horman <horms+renesas@...>
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
drivers/pinctrl/sh-pfc/core.c | 124 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 124 insertions(+)

diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index 310b0dd..2c8c7b2 100644
--- a/drivers/pinctrl/sh-pfc/core.c
+++ b/drivers/pinctrl/sh-pfc/core.c
@@ -568,6 +568,13 @@ static const struct of_device_id sh_pfc_of_table[] = {
.compatible = "renesas,pfc-r8a7795",
.data = &r8a7795_pinmux_info,
},
+#ifdef DEBUG
+ {
+ /* For sanity checks only (nothing matches against this) */
+ .compatible = "renesas,pfc-r8a77950", /* R-Car H3 ES1.0 */
+ .data = &r8a7795es1_pinmux_info,
+ },
+#endif /* DEBUG */
#endif
#ifdef CONFIG_PINCTRL_PFC_R8A7796
{
@@ -706,6 +713,122 @@ static int sh_pfc_suspend_init(struct sh_pfc *pfc) { return 0; }
#define DEV_PM_OPS NULL
#endif /* CONFIG_PM_SLEEP && CONFIG_ARM_PSCI_FW */

+#ifdef DEBUG
+static bool is0s(const u16 *enum_ids, unsigned int n)
+{
+ unsigned int i;
+
+ for (i = 0; i < n; i++)
+ if (enum_ids[i])
+ return false;
+
+ return true;
+}
+
+static unsigned int sh_pfc_errors;
+static unsigned int sh_pfc_warnings;
+
+static void sh_pfc_check_cfg_reg(const char *drvname,
+ const struct pinmux_cfg_reg *cfg_reg)
+{
+ unsigned int i, n, rw, fw;
+
+ if (cfg_reg->field_width) {
+ /* Checked at build time */
+ return;
+ }
+
+ for (i = 0, n = 0, rw = 0; (fw = cfg_reg->var_field_width[i]); i++) {
+ if (fw > 3 && is0s(&cfg_reg->enum_ids[n], 1 << fw)) {
+ pr_warn("%s: reg 0x%x: reserved field [%u:%u] can be split to reduce table size\n",
+ drvname, cfg_reg->reg, rw, rw + fw - 1);
+ sh_pfc_warnings++;
+ }
+ n += 1 << fw;
+ rw += fw;
+ }
+
+ if (rw != cfg_reg->reg_width) {
+ pr_err("%s: reg 0x%x: var_field_width declares %u instead of %u bits\n",
+ drvname, cfg_reg->reg, rw, cfg_reg->reg_width);
+ sh_pfc_errors++;
+ }
+}
+
+static void sh_pfc_check_info(const struct sh_pfc_soc_info *info)
+{
+ const struct sh_pfc_function *func;
+ const char *drvname = info->name;
+ unsigned int *refcnts;
+ unsigned int i, j, k;
+
+ pr_info("Checking %s\n", drvname);
+
+ /* Check groups and functions */
+ refcnts = kcalloc(info->nr_groups, sizeof(*refcnts), GFP_KERNEL);
+ if (!refcnts)
+ return;
+
+ for (i = 0; i < info->nr_functions; i++) {
+ func = &info->functions[i];
+ for (j = 0; j < func->nr_groups; j++) {
+ for (k = 0; k < info->nr_groups; k++) {
+ if (!strcmp(func->groups[j],
+ info->groups[k].name)) {
+ refcnts[k]++;
+ break;
+ }
+ }
+
+ if (k == info->nr_groups) {
+ pr_err("%s: function %s: group %s not found\n",
+ drvname, func->name, func->groups[j]);
+ sh_pfc_errors++;
+ }
+ }
+ }
+
+ for (i = 0; i < info->nr_groups; i++) {
+ if (!refcnts[i]) {
+ pr_err("%s: orphan group %s\n", drvname,
+ info->groups[i].name);
+ sh_pfc_errors++;
+ } else if (refcnts[i] > 1) {
+ pr_err("%s: group %s referred by %u functions\n",
+ drvname, info->groups[i].name, refcnts[i]);
+ sh_pfc_warnings++;
+ }
+ }
+
+ kfree(refcnts);
+
+ /* Check config register descriptions */
+ for (i = 0; info->cfg_regs && info->cfg_regs[i].reg; i++)
+ sh_pfc_check_cfg_reg(drvname, &info->cfg_regs[i]);
+}
+
+static void sh_pfc_check_driver(const struct platform_driver *pdrv)
+{
+ unsigned int i;
+
+ pr_warn("Checking builtin pinmux tables\n");
+
+ for (i = 0; pdrv->id_table[i].name[0]; i++)
+ sh_pfc_check_info((void *)pdrv->id_table[i].driver_data);
+
+#ifdef CONFIG_OF
+ for (i = 0; pdrv->driver.of_match_table[i].compatible[0]; i++)
+ sh_pfc_check_info(pdrv->driver.of_match_table[i].data);
+#endif
+
+ pr_warn("Detected %u errors and %u warnings\n", sh_pfc_errors,
+ sh_pfc_warnings);
+}
+
+#else /* !DEBUG */
+static inline void sh_pfc_check_driver(struct platform_driver *pdrv) {}
+#endif /* !DEBUG */
+
static int sh_pfc_probe(struct platform_device *pdev)
{
#ifdef CONFIG_OF
@@ -837,6 +960,7 @@ static struct platform_driver sh_pfc_driver = {

static int __init sh_pfc_init(void)
{
+ sh_pfc_check_driver(&sh_pfc_driver);
return platform_driver_register(&sh_pfc_driver);
}
postcore_initcall(sh_pfc_init);
--
2.7.4


[PATCH/RFC 4.19.y-cip v2 01/51] pinctrl: sh-pfc: Print actual field width for variable-width fields

Fabrizio Castro <fabrizio.castro@...>
 

From: Geert Uytterhoeven <geert+renesas@...>

commit ce16e8dd0db2701265e6dfdb4fbed632b6ff61c2 upstream.

The debug code in sh_pfc_write_config_reg() prints the width of the
field being modified.

However, registers with a variable-width field layout are identified by
pinmux_cfg_reg.field_width being zero, hence zeroes are printed instead
of the actual field widths.

Fix this by printing the Hamming weight of the field mask instead, which
is correct for both fixed-width and variable-width fields.

Signed-off-by: Geert Uytterhoeven <geert+renesas@...>
Reviewed-by: Simon Horman <horms+renesas@...>
Signed-off-by: Fabrizio Castro <fabrizio.castro@...>
---
drivers/pinctrl/sh-pfc/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index 4f835b6..310b0dd 100644
--- a/drivers/pinctrl/sh-pfc/core.c
+++ b/drivers/pinctrl/sh-pfc/core.c
@@ -224,7 +224,7 @@ static void sh_pfc_write_config_reg(struct sh_pfc *pfc,

dev_dbg(pfc->dev, "write_reg addr = %x, value = 0x%x, field = %u, "
"r_width = %u, f_width = %u\n",
- crp->reg, value, field, crp->reg_width, crp->field_width);
+ crp->reg, value, field, crp->reg_width, hweight32(mask));

mask = ~(mask << pos);
value = value << pos;
--
2.7.4


[PATCH/RFC 4.19.y-cip v2 00/51] Fast forward sh-pfc

Fabrizio Castro <fabrizio.castro@...>
 

Dear All,

v1 had build time issues on ARM with shmobile_defconfig, this series
includes the patches to fix those issues (and some cosmetic improvements
while at it).
The troublesome SoC specific pinctrl drivers are not related to the
SoCs looked after by CIP, therefore we would not be testing those
fixes on real HW.
I am not sure this series is worth applying due to the amount of untested
changes, and yet on the other hand it would facilitate future development.
I would like to hear your thoughts about this, Pavel? Chris? Biju? Ben?

v1->v2:
* add "pinctrl: sh-pfc: sh73a0: Use new macros for non-GPIO pins"
* add "pinctrl: sh-pfc: sh73a0: Add missing TO pin to tpu4_to3 group"
* add "pinctrl: sh-pfc: sh73a0: Fix fsic_spdif pin groups"
* add "pinctrl: sh-pfc: r8a7791: Fix scifb2_data_c pin group"
* add "pinctrl: sh-pfc: r8a7791: Fix VIN1 versioned groups"
* add "pinctrl: sh-pfc: r8a7791: Remove bogus marks from vin1_b_data18 group"
* add "pinctrl: sh-pfc: r8a7791: Remove bogus ctrl marks from qspi_data4_b group"
* add "pinctrl: sh-pfc: r8a7740: Add missing LCD0 marks to lcd0_data24_1 group"
* add "pinctrl: sh-pfc: r8a7740: Add missing REF125CK pin to gether_gmii group"
* add "pinctrl: sh-pfc: r8a77995: Remove unused PINMUX_IPSR_{MSEL2,PHYS}()"

Thanks,
Fab

Fabrizio Castro (2):
pinctrl: sh-pfc: r8a7796: Move CANFD pin groups and functions
pinctrl: sh-pfc: r8a77990: Move CANFD pin groups and functions

Geert Uytterhoeven (36):
pinctrl: sh-pfc: Print actual field width for variable-width fields
pinctrl: sh-pfc: Validate pinmux tables at runtime when debugging
pinctrl: sh-pfc: Validate pins/marks in pin groups at build time
pinctrl: sh-pfc: Make pinmux_cfg_reg.var_field_width[] variable-length
pinctrl: sh-pfc: Validate fixed-size field widths at build time
pinctrl: sh-pfc: Absorb enum IDs in PINMUX_CFG_REG() macro
pinctrl: sh-pfc: Absorb enum IDs in PINMUX_CFG_REG_VAR() macro
pinctrl: sh-pfc: Absorb enum IDs in PINMUX_DATA_REG() macro
pinctrl: sh-pfc: Validate enum IDs for regs with fixed-width fields
pinctrl: sh-pfc: Validate enum IDs for regs with variable-width fields
pinctrl: sh-pfc: Improve PINMUX_IPSR_PHYS() documentation
pinctrl: sh-pfc: Rename 2-parameter CPU_ALL_PORT() variant
pinctrl: sh-pfc: Add SH_PFC_PIN_CFG_PULL_UP_DOWN shorthand
pinctrl: sh-pfc: Add new non-GPIO helper macros
pinctrl: sh-pfc: Correct printk level of group reference warning
pinctrl: sh-pfc: Mark run-time debug code __init
pinctrl: sh-pfc: Add check for empty pinmux groups/functions
pinctrl: sh-pfc: Validate pin tables at runtime
pinctrl: sh-pfc: r8a7796: Deduplicate VIN5 pin definitions
pinctrl: sh-pfc: r8a77990: Rename IOCTRLx registers
pinctrl: sh-pfc: Add missing #include <linux/errno.h>
pinctrl: sh-pfc: Add PORT_GP_27 helper macro
pinctrl: sh-pfc: Move PIN_NONE to shared header file
pinctrl: sh-pfc: r8a77990: Use new macros for non-GPIO pins
pinctrl: sh-pfc: r8a7796: Add TPU pins, groups and functions
pinctrl: sh-pfc: r8a7796: Use new macros for non-GPIO pins
pinctrl: sh-pfc: r8a77995: Remove unused PINMUX_IPSR_{MSEL2,PHYS}()
pinctrl: sh-pfc: r8a7740: Add missing REF125CK pin to gether_gmii
group
pinctrl: sh-pfc: r8a7740: Add missing LCD0 marks to lcd0_data24_1
group
pinctrl: sh-pfc: r8a7791: Remove bogus ctrl marks from qspi_data4_b
group
pinctrl: sh-pfc: r8a7791: Remove bogus marks from vin1_b_data18 group
pinctrl: sh-pfc: r8a7791: Fix VIN1 versioned groups
pinctrl: sh-pfc: r8a7791: Fix scifb2_data_c pin group
pinctrl: sh-pfc: sh73a0: Fix fsic_spdif pin groups
pinctrl: sh-pfc: sh73a0: Add missing TO pin to tpu4_to3 group
pinctrl: sh-pfc: sh73a0: Use new macros for non-GPIO pins

Jacopo Mondi (1):
pinctrl: sh-pfc: r8a7796: Fix VIN versioned groups

Marek Vasut (1):
pinctrl: sh-pfc: rcar-gen3: Retain TDSELCTRL register across
suspend/resume

Takeshi Kihara (9):
pinctrl: sh-pfc: r8a7796: Add I2C{0,3,5} pins, groups and functions
pinctrl: sh-pfc: rcar-gen3: Remove HDMI CEC pins, groups, and
functions
pinctrl: sh-pfc: rcar-gen3: Remove CC5_OSCOUT pin
pinctrl: sh-pfc: rcar-gen3: Rename SEL_ADG_{A,B,C} to SEL_ADG{A,B,C}
pinctrl: sh-pfc: r8a77990: Fix MOD_SEL0 bit16 when using NFALE and
NFRB_N
pinctrl: sh-pfc: r8a77990: Fix MOD_SEL1 bit31 when using SIM0_D
pinctrl: sh-pfc: r8a77990: Fix MOD_SEL1 bit30 when using SSI_SCK2 and
SSI_WS2
pinctrl: sh-pfc: rcar-gen3: Rename RTS{0,1,3,4}# pin function
definitions
pinctrl: sh-pfc: rcar-gen3: Rename SEL_NDFC to SEL_NDF

Ulrich Hecht (2):
pinctrl: sh-pfc: Add physical pin multiplexing helper macros
pinctrl: sh-pfc: r8a7796: Remove placeholder I2C pin data

drivers/pinctrl/sh-pfc/core.c | 172 ++++++-
drivers/pinctrl/sh-pfc/pfc-emev2.c | 67 +--
drivers/pinctrl/sh-pfc/pfc-r8a73a4.c | 66 +--
drivers/pinctrl/sh-pfc/pfc-r8a7740.c | 61 +--
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 138 ++---
drivers/pinctrl/sh-pfc/pfc-r8a7778.c | 179 ++++---
drivers/pinctrl/sh-pfc/pfc-r8a7779.c | 119 +++--
drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 134 ++---
drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 234 +++++----
drivers/pinctrl/sh-pfc/pfc-r8a7792.c | 136 ++---
drivers/pinctrl/sh-pfc/pfc-r8a7794.c | 129 +++--
drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c | 239 ++++-----
drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 266 +++++-----
drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 837 ++++++++++++++++---------------
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 254 +++++-----
drivers/pinctrl/sh-pfc/pfc-r8a77970.c | 73 +--
drivers/pinctrl/sh-pfc/pfc-r8a77980.c | 81 +--
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 395 +++++++--------
drivers/pinctrl/sh-pfc/pfc-r8a77995.c | 106 ++--
drivers/pinctrl/sh-pfc/pfc-sh7203.c | 152 +++---
drivers/pinctrl/sh-pfc/pfc-sh7264.c | 232 ++++-----
drivers/pinctrl/sh-pfc/pfc-sh7269.c | 252 +++++-----
drivers/pinctrl/sh-pfc/pfc-sh73a0.c | 75 +--
drivers/pinctrl/sh-pfc/pfc-sh7720.c | 144 +++---
drivers/pinctrl/sh-pfc/pfc-sh7722.c | 220 ++++----
drivers/pinctrl/sh-pfc/pfc-sh7723.c | 200 ++++----
drivers/pinctrl/sh-pfc/pfc-sh7724.c | 204 ++++----
drivers/pinctrl/sh-pfc/pfc-sh7734.c | 142 +++---
drivers/pinctrl/sh-pfc/pfc-sh7757.c | 244 ++++-----
drivers/pinctrl/sh-pfc/pfc-sh7785.c | 136 ++---
drivers/pinctrl/sh-pfc/pfc-sh7786.c | 80 +--
drivers/pinctrl/sh-pfc/pfc-shx3.c | 32 +-
drivers/pinctrl/sh-pfc/pinctrl.c | 3 +-
drivers/pinctrl/sh-pfc/sh_pfc.h | 163 ++++--
34 files changed, 3187 insertions(+), 2778 deletions(-)

--
2.7.4


Re: [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Ben Hutchings <ben.hutchings@...>
 

On Thu, 2019-08-29 at 11:04 +0000, Fabrizio Castro wrote:
Hello Chris,

Thank you for your feedback!

From: Chris Paterson <Chris.Paterson2@...>
Sent: 29 August 2019 11:23
Subject: RE: [cip-dev] [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Hello Pavel, Fab,

From: cip-dev-bounces@... <cip-dev-bounces@...
project.org> On Behalf Of Fabrizio Castro
Sent: 29 August 2019 10:50

Hi Pavel,

From: Pavel Machek <pavel@...>
Sent: 29 August 2019 10:48
Subject: Re: [cip-dev] [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Hi!

they have made good progress upstream with the development of
sh-pfc,
and although the functionality of the drivers hasn't changed much,
the code looks fairly different. This means that backporting patches
to SoC specific driver files will be increasingly hard and error
prone, unless we fast-forward the code base for 4.19.y-cip, hence
this series.
What do you gus think? Comments welcome!
I reviewed the patches... and it is interesting how much magic can be
done with preprocessor.
I thought the same thing!
I do not see anything preventing the merge, but they were marked
[rfc]
so I'm not doing that yet. Let me know if I should.
Since nothing nasty was spotted during code review and it works ok, I
believe
merging this series could really help us with future development, so yes
please, go ahead and merge.
Ok, merged, and pushed out.
Our CI is hitting some build errors with the latest v4.19-cip (commit b11ac993) with the renesas shmobile_defconfig configurations:
https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/283063646
https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/283063654

In file included from ./include/linux/kernel.h:15,
from ./include/asm-generic/bug.h:18,
from ./arch/arm/include/asm/bug.h:60,
from ./include/linux/bug.h:5,
from ./include/linux/io.h:23,
from drivers/pinctrl/sh-pfc/pfc-r8a7740.c:21:
./include/linux/build_bug.h:29:45: error: negative width in bit-field '<anonymous>'
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
^
drivers/pinctrl/sh-pfc/sh_pfc.h:52:3: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
BUILD_BUG_ON_ZERO(sizeof(n##_pins) != sizeof(n##_mux)), \
^~~~~~~~~~~~~~~~~
drivers/pinctrl/sh-pfc/sh_pfc.h:54:29: note: in expansion of macro 'SH_PFC_PIN_GROUP_ALIAS'
#define SH_PFC_PIN_GROUP(n) SH_PFC_PIN_GROUP_ALIAS(n, n)
^~~~~~~~~~~~~~~~~~~~~~
drivers/pinctrl/sh-pfc/pfc-r8a7740.c:2806:2: note: in expansion of macro 'SH_PFC_PIN_GROUP'
SH_PFC_PIN_GROUP(gether_gmii),
^~~~~~~~~~~~~~~~
[...]
Thank you for reporting this, and I am so glad we have CI in place to spot this things early on now.

I think the safest thing to do here is dropping this series after seeing the build log,
there is clearly more effort needed to keep arm32 and arm64 in check, and backporting
more patches to the sh-pfc driver would still be a pain.

Pavel, do you think you can drop this series?
The failing assertions were added by "pinctrl: sh-pfc: Validate
pins/marks in pin groups at build time". We could revert that one
patch, but it seems to be detecting actual bugs in r8a7740.c, so I
think we should take the fixes for those:

commit 1ebc589a7786f17f97b9e87b44e0fb4d0290d8f8
Author: Geert Uytterhoeven <geert+renesas@...>
Date: Wed Dec 12 10:57:27 2018 +0100

pinctrl: sh-pfc: r8a7740: Add missing REF125CK pin to gether_gmii group

commit 96bb2a6ab4eca10e5b6490b3f0738e9f7ec22c2b
Author: Geert Uytterhoeven <geert+renesas@...>
Date: Wed Dec 12 11:00:27 2018 +0100

pinctrl: sh-pfc: r8a7740: Add missing LCD0 marks to lcd0_data24_1 group

Ben.

--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom


Re: [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Fabrizio Castro <fabrizio.castro@...>
 

Hello Chris,

Thank you for your feedback!

From: Chris Paterson <Chris.Paterson2@...>
Sent: 29 August 2019 11:23
Subject: RE: [cip-dev] [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Hello Pavel, Fab,

From: cip-dev-bounces@... <cip-dev-bounces@...
project.org> On Behalf Of Fabrizio Castro
Sent: 29 August 2019 10:50

Hi Pavel,

From: Pavel Machek <pavel@...>
Sent: 29 August 2019 10:48
Subject: Re: [cip-dev] [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Hi!

they have made good progress upstream with the development of
sh-pfc,
and although the functionality of the drivers hasn't changed much,
the code looks fairly different. This means that backporting patches
to SoC specific driver files will be increasingly hard and error
prone, unless we fast-forward the code base for 4.19.y-cip, hence
this series.
What do you gus think? Comments welcome!
I reviewed the patches... and it is interesting how much magic can be
done with preprocessor.
I thought the same thing!
I do not see anything preventing the merge, but they were marked
[rfc]
so I'm not doing that yet. Let me know if I should.
Since nothing nasty was spotted during code review and it works ok, I
believe
merging this series could really help us with future development, so yes
please, go ahead and merge.
Ok, merged, and pushed out.
Our CI is hitting some build errors with the latest v4.19-cip (commit b11ac993) with the renesas shmobile_defconfig configurations:
https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/283063646
https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/283063654

In file included from ./include/linux/kernel.h:15,
from ./include/asm-generic/bug.h:18,
from ./arch/arm/include/asm/bug.h:60,
from ./include/linux/bug.h:5,
from ./include/linux/io.h:23,
from drivers/pinctrl/sh-pfc/pfc-r8a7740.c:21:
./include/linux/build_bug.h:29:45: error: negative width in bit-field '<anonymous>'
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
^
drivers/pinctrl/sh-pfc/sh_pfc.h:52:3: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
BUILD_BUG_ON_ZERO(sizeof(n##_pins) != sizeof(n##_mux)), \
^~~~~~~~~~~~~~~~~
drivers/pinctrl/sh-pfc/sh_pfc.h:54:29: note: in expansion of macro 'SH_PFC_PIN_GROUP_ALIAS'
#define SH_PFC_PIN_GROUP(n) SH_PFC_PIN_GROUP_ALIAS(n, n)
^~~~~~~~~~~~~~~~~~~~~~
drivers/pinctrl/sh-pfc/pfc-r8a7740.c:2806:2: note: in expansion of macro 'SH_PFC_PIN_GROUP'
SH_PFC_PIN_GROUP(gether_gmii),
^~~~~~~~~~~~~~~~
./include/linux/build_bug.h:29:45: error: negative width in bit-field '<anonymous>'
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
^
drivers/pinctrl/sh-pfc/sh_pfc.h:52:3: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
BUILD_BUG_ON_ZERO(sizeof(n##_pins) != sizeof(n##_mux)), \
^~~~~~~~~~~~~~~~~
drivers/pinctrl/sh-pfc/sh_pfc.h:54:29: note: in expansion of macro 'SH_PFC_PIN_GROUP_ALIAS'
#define SH_PFC_PIN_GROUP(n) SH_PFC_PIN_GROUP_ALIAS(n, n)
^~~~~~~~~~~~~~~~~~~~~~
drivers/pinctrl/sh-pfc/pfc-r8a7740.c:2868:2: note: in expansion of macro 'SH_PFC_PIN_GROUP'
SH_PFC_PIN_GROUP(lcd0_data24_1),
^~~~~~~~~~~~~~~~
make[3]: *** [drivers/pinctrl/sh-pfc/pfc-r8a7740.o] Error 1
scripts/Makefile.build:303: recipe for target 'drivers/pinctrl/sh-pfc/pfc-r8a7740.o' failed
make[2]: *** [drivers/pinctrl/sh-pfc] Error 2
make[2]: *** Waiting for unfinished jobs....
scripts/Makefile.build:544: recipe for target 'drivers/pinctrl/sh-pfc' failed
AR drivers/pps/clients/built-in.a
AR drivers/pps/generators/built-in.a
CC drivers/pps/pps.o
CC drivers/power/supply/power_supply_sysfs.o
CC drivers/ptp/ptp_clock.o
make[1]: *** [drivers/pinctrl] Error 2
scripts/Makefile.build:544: recipe for target 'drivers/pinctrl' failed
make[1]: *** Waiting for unfinished jobs....
CC drivers/ptp/ptp_chardev.o
AR drivers/power/supply/built-in.a
AR drivers/power/built-in.a
CC drivers/ptp/ptp_sysfs.o
CC drivers/pps/kapi.o
CC drivers/pps/sysfs.o
AR drivers/ptp/built-in.a
AR drivers/pps/built-in.a
make: *** [drivers] Error 2
Makefile:1046: recipe for target 'drivers' failed


Complete pipeline is still running:
https://gitlab.com/cip-project/cip-kernel/linux-cip/pipelines/79117946
Thank you for reporting this, and I am so glad we have CI in place to spot this things early on now.

I think the safest thing to do here is dropping this series after seeing the build log,
there is clearly more effort needed to keep arm32 and arm64 in check, and backporting
more patches to the sh-pfc driver would still be a pain.

Pavel, do you think you can drop this series?

Thanks,
Fab



Kind regards, Chris


Thanks!

Fab


Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Chris Paterson
 

Hello Pavel, Fab,

From: cip-dev-bounces@... <cip-dev-bounces@...
project.org> On Behalf Of Fabrizio Castro
Sent: 29 August 2019 10:50

Hi Pavel,

From: Pavel Machek <pavel@...>
Sent: 29 August 2019 10:48
Subject: Re: [cip-dev] [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Hi!

they have made good progress upstream with the development of
sh-pfc,
and although the functionality of the drivers hasn't changed much,
the code looks fairly different. This means that backporting patches
to SoC specific driver files will be increasingly hard and error
prone, unless we fast-forward the code base for 4.19.y-cip, hence
this series.
What do you gus think? Comments welcome!
I reviewed the patches... and it is interesting how much magic can be
done with preprocessor.
I thought the same thing!
I do not see anything preventing the merge, but they were marked
[rfc]
so I'm not doing that yet. Let me know if I should.
Since nothing nasty was spotted during code review and it works ok, I
believe
merging this series could really help us with future development, so yes
please, go ahead and merge.
Ok, merged, and pushed out.
Our CI is hitting some build errors with the latest v4.19-cip (commit b11ac993) with the renesas shmobile_defconfig configurations:
https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/283063646
https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/283063654

In file included from ./include/linux/kernel.h:15,
from ./include/asm-generic/bug.h:18,
from ./arch/arm/include/asm/bug.h:60,
from ./include/linux/bug.h:5,
from ./include/linux/io.h:23,
from drivers/pinctrl/sh-pfc/pfc-r8a7740.c:21:
./include/linux/build_bug.h:29:45: error: negative width in bit-field '<anonymous>'
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
^
drivers/pinctrl/sh-pfc/sh_pfc.h:52:3: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
BUILD_BUG_ON_ZERO(sizeof(n##_pins) != sizeof(n##_mux)), \
^~~~~~~~~~~~~~~~~
drivers/pinctrl/sh-pfc/sh_pfc.h:54:29: note: in expansion of macro 'SH_PFC_PIN_GROUP_ALIAS'
#define SH_PFC_PIN_GROUP(n) SH_PFC_PIN_GROUP_ALIAS(n, n)
^~~~~~~~~~~~~~~~~~~~~~
drivers/pinctrl/sh-pfc/pfc-r8a7740.c:2806:2: note: in expansion of macro 'SH_PFC_PIN_GROUP'
SH_PFC_PIN_GROUP(gether_gmii),
^~~~~~~~~~~~~~~~
./include/linux/build_bug.h:29:45: error: negative width in bit-field '<anonymous>'
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
^
drivers/pinctrl/sh-pfc/sh_pfc.h:52:3: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
BUILD_BUG_ON_ZERO(sizeof(n##_pins) != sizeof(n##_mux)), \
^~~~~~~~~~~~~~~~~
drivers/pinctrl/sh-pfc/sh_pfc.h:54:29: note: in expansion of macro 'SH_PFC_PIN_GROUP_ALIAS'
#define SH_PFC_PIN_GROUP(n) SH_PFC_PIN_GROUP_ALIAS(n, n)
^~~~~~~~~~~~~~~~~~~~~~
drivers/pinctrl/sh-pfc/pfc-r8a7740.c:2868:2: note: in expansion of macro 'SH_PFC_PIN_GROUP'
SH_PFC_PIN_GROUP(lcd0_data24_1),
^~~~~~~~~~~~~~~~
make[3]: *** [drivers/pinctrl/sh-pfc/pfc-r8a7740.o] Error 1
scripts/Makefile.build:303: recipe for target 'drivers/pinctrl/sh-pfc/pfc-r8a7740.o' failed
make[2]: *** [drivers/pinctrl/sh-pfc] Error 2
make[2]: *** Waiting for unfinished jobs....
scripts/Makefile.build:544: recipe for target 'drivers/pinctrl/sh-pfc' failed
AR drivers/pps/clients/built-in.a
AR drivers/pps/generators/built-in.a
CC drivers/pps/pps.o
CC drivers/power/supply/power_supply_sysfs.o
CC drivers/ptp/ptp_clock.o
make[1]: *** [drivers/pinctrl] Error 2
scripts/Makefile.build:544: recipe for target 'drivers/pinctrl' failed
make[1]: *** Waiting for unfinished jobs....
CC drivers/ptp/ptp_chardev.o
AR drivers/power/supply/built-in.a
AR drivers/power/built-in.a
CC drivers/ptp/ptp_sysfs.o
CC drivers/pps/kapi.o
CC drivers/pps/sysfs.o
AR drivers/ptp/built-in.a
AR drivers/pps/built-in.a
make: *** [drivers] Error 2
Makefile:1046: recipe for target 'drivers' failed


Complete pipeline is still running:
https://gitlab.com/cip-project/cip-kernel/linux-cip/pipelines/79117946


Kind regards, Chris


Thanks!

Fab


Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Fabrizio Castro <fabrizio.castro@...>
 

Hi Pavel,

From: Pavel Machek <pavel@...>
Sent: 29 August 2019 10:48
Subject: Re: [cip-dev] [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Hi!

they have made good progress upstream with the development of sh-pfc,
and although the functionality of the drivers hasn't changed much,
the code looks fairly different. This means that backporting patches
to SoC specific driver files will be increasingly hard and error
prone, unless we fast-forward the code base for 4.19.y-cip, hence
this series.
What do you gus think? Comments welcome!
I reviewed the patches... and it is interesting how much magic can be
done with preprocessor.
I thought the same thing!
I do not see anything preventing the merge, but they were marked [rfc]
so I'm not doing that yet. Let me know if I should.
Since nothing nasty was spotted during code review and it works ok, I believe
merging this series could really help us with future development, so yes
please, go ahead and merge.
Ok, merged, and pushed out.
Thanks!

Fab


Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Pavel Machek
 

Hi!

they have made good progress upstream with the development of sh-pfc,
and although the functionality of the drivers hasn't changed much,
the code looks fairly different. This means that backporting patches
to SoC specific driver files will be increasingly hard and error
prone, unless we fast-forward the code base for 4.19.y-cip, hence
this series.
What do you gus think? Comments welcome!
I reviewed the patches... and it is interesting how much magic can be
done with preprocessor.
I thought the same thing!
I do not see anything preventing the merge, but they were marked [rfc]
so I'm not doing that yet. Let me know if I should.
Since nothing nasty was spotted during code review and it works ok, I believe
merging this series could really help us with future development, so yes
please, go ahead and merge.
Ok, merged, and pushed out.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Fabrizio Castro <fabrizio.castro@...>
 

Hi Pavel,

Thank you for your feedback!

From: Pavel Machek <pavel@...>
Sent: 29 August 2019 09:12
Subject: Re: [cip-dev] [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Hi!

they have made good progress upstream with the development of sh-pfc,
and although the functionality of the drivers hasn't changed much,
the code looks fairly different. This means that backporting patches
to SoC specific driver files will be increasingly hard and error
prone, unless we fast-forward the code base for 4.19.y-cip, hence
this series.
What do you gus think? Comments welcome!
I reviewed the patches... and it is interesting how much magic can be
done with preprocessor.
I thought the same thing!


I do not see anything preventing the merge, but they were marked [rfc]
so I'm not doing that yet. Let me know if I should.
Since nothing nasty was spotted during code review and it works ok, I believe
merging this series could really help us with future development, so yes
please, go ahead and merge.

Thanks!

Fab


Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH/RFC 4.19.y-cip 07/41] pinctrl: sh-pfc: Absorb enum IDs in PINMUX_CFG_REG() macro

Fabrizio Castro <fabrizio.castro@...>
 

Hello Pavel,

Thank you for your feedback!

From: Pavel Machek <pavel@...>
Sent: 29 August 2019 09:09
Subject: Re: [cip-dev] [PATCH/RFC 4.19.y-cip 07/41] pinctrl: sh-pfc: Absorb enum IDs in PINMUX_CFG_REG() macro

Hi!

commit efca8da0c5fcc7f5617bab769faa595f7efdc593 upstream.

Currently the PINMUX_CFG_REG() macro must be followed by initialization
data, specifying all enum IDs. Hence the macro itself does not know
anything about the enum IDs, preventing the macro from performing any
validation on it.

Make the macro accept the enum IDs as a parameter, and update all users.
Note that array data enclosed by curly braces cannot be passed to a
macro as a parameter, hence the enum IDs are wrapped using a new macro
GROUPS().
The macro is called "GROUP" and we already have macros with same name
(but different functionality) in the tree.

One of the other uses is ./arch/sh/kernel/cpu/sh4a/setup-sh7734.c. Not
sure if it is huge problem, but it might be a bit confusing...

./drivers/pinctrl/sirf/pinctrl-atlas7.c:#define GROUP(n, p) \
./drivers/pinctrl/meson/pinctrl-meson-axg-pmx.h:#define GROUP(grp, f)
./drivers/pinctrl/meson/pinctrl-meson8-pmx.h:#define GROUP(grp, r, b)
./drivers/input/rmi4/rmi_driver.h:#define GROUP(_attrs) { \
./arch/sh/kernel/cpu/sh4a/setup-sh7734.c:#define GROUP 0
To me it looks like all of those definitions are local to the corresponding
drivers, and so is the GROUP definition for the sh-pfc driver:
linux$ find . -iname "*.c" -exec grep -Hn "sh_pfc\.h" '{}' \;
./drivers/pinctrl/sh-pfc/pfc-r8a77970.c:20:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-sh7203.c:12:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-sh7264.c:12:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-sh7785.c:12:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a7794.c:15:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-sh7757.c:17:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a77995.c:18:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a77965.c:19:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a7795.c:13:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-sh73a0.c:17:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a7740.c:12:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-emev2.c:10:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a7790.c:17:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-sh7269.c:13:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a7791.c:12:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a7796.c:18:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a77990.c:18:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-sh7786.c:17:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a73a4.c:11:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-shx3.c:11:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-sh7734.c:12:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a77470.c:11:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a7778.c:20:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a77980.c:20:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c:12:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-sh7720.c:12:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-sh7724.c:17:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-sh7722.c:7:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-sh7723.c:12:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a7779.c:12:#include "sh_pfc.h"
./drivers/pinctrl/sh-pfc/pfc-r8a7792.c:12:#include "sh_pfc.h"
linux$ find . -iname "*.h" -exec grep -Hn "sh_pfc\.h" '{}' \;
./drivers/pinctrl/sh-pfc/core.h:12:#include "sh_pfc.h"

I think this is ok for both upstream and 4.19.y-cip.

Thanks,
Fab


Best regards,
Pavel

+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -118,20 +118,24 @@ struct pinmux_cfg_reg {
const u8 *var_field_width;
};

+#define GROUP(...) __VA_ARGS__
+
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH/RFC 4.19.y-cip 00/41] Fast forward sh-pfc

Pavel Machek
 

Hi!

they have made good progress upstream with the development of sh-pfc,
and although the functionality of the drivers hasn't changed much,
the code looks fairly different. This means that backporting patches
to SoC specific driver files will be increasingly hard and error
prone, unless we fast-forward the code base for 4.19.y-cip, hence
this series.
What do you gus think? Comments welcome!
I reviewed the patches... and it is interesting how much magic can be
done with preprocessor.

I do not see anything preventing the merge, but they were marked [rfc]
so I'm not doing that yet. Let me know if I should.

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH/RFC 4.19.y-cip 07/41] pinctrl: sh-pfc: Absorb enum IDs in PINMUX_CFG_REG() macro

Pavel Machek
 

Hi!

commit efca8da0c5fcc7f5617bab769faa595f7efdc593 upstream.

Currently the PINMUX_CFG_REG() macro must be followed by initialization
data, specifying all enum IDs. Hence the macro itself does not know
anything about the enum IDs, preventing the macro from performing any
validation on it.

Make the macro accept the enum IDs as a parameter, and update all users.
Note that array data enclosed by curly braces cannot be passed to a
macro as a parameter, hence the enum IDs are wrapped using a new macro
GROUPS().
The macro is called "GROUP" and we already have macros with same name
(but different functionality) in the tree.

One of the other uses is ./arch/sh/kernel/cpu/sh4a/setup-sh7734.c. Not
sure if it is huge problem, but it might be a bit confusing...

./drivers/pinctrl/sirf/pinctrl-atlas7.c:#define GROUP(n, p) \
./drivers/pinctrl/meson/pinctrl-meson-axg-pmx.h:#define GROUP(grp, f)
./drivers/pinctrl/meson/pinctrl-meson8-pmx.h:#define GROUP(grp, r, b)
./drivers/input/rmi4/rmi_driver.h:#define GROUP(_attrs) { \
./arch/sh/kernel/cpu/sh4a/setup-sh7734.c:#define GROUP 0

Best regards,
Pavel

+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -118,20 +118,24 @@ struct pinmux_cfg_reg {
const u8 *var_field_width;
};

+#define GROUP(...) __VA_ARGS__
+
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 1/3] Change templagte directory name

Chris Paterson
 


Thank you for this patch. Do you think you could create a merge request
in gitlab[0] so we can do the review there?
For this patch and the other two in the series.

[0]
https://gitlab.com/cip-project/cip-testing/linux-cip-ci/merge_reques
ts
Ok, I just sent MR via gitlab.
Thanks!

Chris



Kind regards, Chris
Best regards,
Nobuhiro


Re: CIP IRC weekly meeting today

masashi.kudo@...
 

SZ-san,

I am sorry, but it turned out that I need to withdraw my request for now.
Let me propose our idea some later time.
I am sorry to confuse you.

Best regards,
--
M. Kudo

2019年8月29日(木) 13:05 SZ Lin (林上智) <SZ.Lin@...>:

Hi Kudo-san,

 

Noted, thank you for your heads up.

 

SZ

 

From: masashi.kudo@... <masashi.kudo@...>
Sent: Thursday, August 29, 2019 10:51 AM
To: SZ Lin (
林上智) <SZ.Lin@...>
Cc: cip-dev@...
Subject: Re: [cip-dev] CIP IRC weekly meeting today

 

Hello, SZ-san, All,

 

Cybertrust has some proposal to the CIP kernel team.

I would appreciate it if you can add "Cybertrust Proposal" to the agenda.

 

Best regards,

--

M. Kudo

Cybertrust Japan Co., Ltd.

 

2019829() 10:31 SZ Lin (林上智) <SZ.Lin@...>:

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=8&day29&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=24

US-West US-East   UK     DE     TW     JP
02:00    05:00   10:00   11:00   17:00   18:00

Channel:
* irc:chat.freenode.net:6667/cip

Agenda:

* Action item
1. Provide the cases to cip-testing to build up the test environment - Iwamatsu-san

2. Ask cip-dev which configurations need testing - patersonc

3. Test LTS (pre)releases directly – patersonc

4. Discuss and make a decision on default compiler's options - kernel team

5. Look for the new maintainer of CIP security tracker – kernel team

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,

SZ Lin, Moxa.
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: [PATCH 4.4.y-cip 00/17] Add USB2.0 support

Pavel Machek
 

On Wed 2019-08-28 09:48:18, Biju Das wrote:
This patch series add USB2.0 support for iWave iwg23s sbc based on RZ/G1C.

This patch series is based on linux-4.4.y-cip and all the patches
in this series are cherry-picked from linux rc tree.
Thanks for the series, applied and pushed out.

Best regards,
Pavel


Biju Das (16):
dt-bindings: phy: rcar-gen2: Add r8a7744 support
dt-bindings: phy: rcar-gen2: Add r8a77470 support
dt-bindings: rcar-gen3-phy-usb2: Add r8a77470 support
phy: phy-rcar-gen2: Add support for r8a77470
phy: rcar-gen3-usb2: Add support for r8a77470
ARM: dts: r8a77470: Add USB-DMAC device nodes
ARM: dts: r8a77470: Add USB PHY DT support
ARM: dts: r8a77470: Add USB2.0 Host (EHCI/OHCI) device
ARM: shmobile: Enable PHY_RCAR_GEN3_USB2 in shmobile_defconfig
ARM: shmobile: Enable USB [EO]HCI HCD PLATFORM support in
shmobile_defconfig
ARM: dts: iwg23s-sbc: Enable USB Phy[01]
ARM: dts: iwg23s-sbc: Enable USB USB2.0 Host
dt-bindings: usb: renesas_usbhs: Add support for r8a7744
dt-bindings: usb: renesas_usbhs: Add support for r8a77470
ARM: dts: r8a77470: Add HSUSB device nodes
ARM: dts: iwg23s-sbc: Enable HS-USB

Yoshihiro Shimoda (1):
phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver

.../devicetree/bindings/phy/rcar-gen2-phy.txt | 48 ++++-
.../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 39 ++++
.../devicetree/bindings/usb/renesas_usbhs.txt | 2 +
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 44 ++++
arch/arm/boot/dts/r8a77470.dtsi | 185 ++++++++++++++++
arch/arm/configs/shmobile_defconfig | 3 +
drivers/phy/Kconfig | 7 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-rcar-gen2.c | 130 ++++++++++--
drivers/phy/phy-rcar-gen3-usb2.c | 236 +++++++++++++++++++++
10 files changed, 682 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
create mode 100644 drivers/phy/phy-rcar-gen3-usb2.c
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.4.y-cip 05/17] phy: phy-rcar-gen2: Add support for r8a77470

Pavel Machek
 

Hi!

PHYS_PER_CHANNEL is 2.

+ const u32 (*select_value)[PHYS_PER_CHANNEL];
This is ... quite "interesting" declaration. Does it actually match the arrays
below?

If I read it correctly:

const u32 (...)[PHYS_PER_CHANNEL]

this is array of two items.

+static const u32 pci_select_value[][PHYS_PER_CHANNEL] = {
+ [0] = { USBHS_UGCTRL2_USB0SEL_PCI,
USBHS_UGCTRL2_USB0SEL_HS_USB },
+ [2] = { USBHS_UGCTRL2_USB2SEL_PCI,
USBHS_UGCTRL2_USB2SEL_USB30 },
+};
But here we have three items (0, 1 and 2), yet we are assigning that to same
pointer.

Correct me if I'm wrong.
Please compile the below code and check the results for 2 dimensional arrays.
I'm sorry, I got confused. Sorry for the noise.

Best regards,
Pavel

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Re: [PATCH 4.19.y-cip v2 00/57] Add basic RZ/G2M SoC support

Nobuhiro Iwamatsu
 

Hi Fabrizio,

Thanks for your patch.
I will check these.

Best regards,
Nobuhiro

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Fabrizio
Castro
Sent: Wednesday, August 28, 2019 10:32 PM
To: cip-dev@...
Cc: Biju Das <biju.das@...>
Subject: [cip-dev] [PATCH 4.19.y-cip v2 00/57] Add basic RZ/G2M SoC
support

Dear All,

this series aims at providing basic RZ/G2M SoC dtsi support.

v1->v2:
* dropped "serial: sh-sci: Fix TX DMA buffer flushing and workqueue races"
* dropped "serial: sh-sci: Terminate TX DMA during buffer flushing"
* dropped "dmaengine: rcar-dmac: Reject zero-length slave DMA requests"

Thanks,
Fab

Biju Das (13):
dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
arm64: dts: renesas: Initial r8a774a1 SoC device tree
arm64: dts: renesas: r8a774a1: Add SYS-DMAC controller nodes
arm64: dts: renesas: r8a774a1: Add INTC-EX device node
arm64: dts: renesas: r8a774a1: Add RWDT node
arm64: dts: renesas: r8a774a1: Add I2C and IIC-DVFS support
arm64: dts: renesas: r8a774a1: Add RZ/G2M thermal support
arm64: dts: renesas: r8a774a1: Add all MSIOF nodes
arm64: dts: renesas: r8a774a1: Add Cortex-A53 CPU cores
arm64: dts: renesas: r8a774a1: Add audio support
arm64: dts: renesas: r8a774a1: Add USB2.0 phy and host(EHCI/OHCI)
device nodes
arm64: dts: renesas: r8a774a1: Add USB-DMAC and HSUSB device nodes
arm64: dts: renesas: r8a774a1: Add USB3.0 device nodes

Chris Paterson (1):
arm64: dts: renesas: r8a774a1: Add CAN nodes

Enrico Weigelt, metux IT consult (1):
gpio: rcar: Pedantic formatting

Fabrizio Castro (21):
dt-bindings: can: rcar_can: Add r8a774a1 support
dt-bindings: can: rcar_can: Fix RZ/G2 CAN clocks
dt-bindings: can: rcar_can: Add r8a774c0 support
dt-bindings: rcar-gen3-phy-usb3: Add r8a774a1 support
dt-bindings: usb-xhci: Add r8a774a1 support
dt-bindings: usb-xhci: Add r8a774c0 support
dt-bindings: usb: renesas_usbhs: Add r8a774a1 support
dt-bindings: thermal: rcar-gen3-thermal: Add r8a774a1 support
thermal: rcar_gen3_thermal: Add r8a774a1 support
arm64: dts: renesas: r8a774a1: Add SCIF and HSCIF nodes
arm64: dts: renesas: r8a774a1: Add Ethernet AVB node
arm64: dts: renesas: r8a774a1: Add pinctrl device node
arm64: dts: renesas: r8a774a1: Add GPIO device nodes
arm64: dts: renesas: r8a774a1: Add SDHI nodes
arm64: dts: renesas: r8a774a1: Add IPMMU device nodes
arm64: dts: renesas: r8a774a1: Add PWM device nodes
arm64: dts: renesas: r8a774a1: Add FCPF and FCPV instances
arm64: dts: renesas: r8a774a1: Replace power magic numbers
arm64: dts: renesas: r8a774a1: Replace clock magic numbers
arm64: dts: renesas: r8a774a1: Fix hsusb reg size
arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes

Geert Uytterhoeven (12):
clk: renesas: cpg-mssr: Use genpd of_node instead of local copy
clk: renesas: cpg-mssr: Remove error messages on out-of-memory
conditions
soc: renesas: rcar-sysc: Remove rcar_sysc_power_{down,up}() helpers
soc: renesas: rcar-sysc: Merge PM Domain registration and linking
soc: renesas: rcar-sysc: Fix power domain control after system resume
serial: sh-sci: Fix crash in rx_timer_fn() on PIO fallback
serial: sh-sci: Extract sci_dma_rx_chan_invalidate()
serial: sh-sci: Extract sci_dma_rx_reenable_irq()
serial: sh-sci: Fix fallback to PIO in sci_dma_rx_complete()
arm64: dts: renesas: Fix whitespace around assignments
arm64: dts: renesas: Remove unneeded status from thermal nodes
arm64: dts: renesas: r8a774a1: Enable DMA for SCIF2

Hiroyuki Yokoyama (1):
dmaengine: rcar-dmac: Update copyright information

Kazuya Mizuguchi (1):
ravb: remove tx buffer addr 4byte alilgnment restriction for R-Car
Gen3

Niklas Söderlund (1):
mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size

Rob Herring (1):
arm64: dts: Remove inconsistent use of 'arm,armv8' compatible string

Sergei Shtylyov (1):
spi: sh-msiof: fix deferred probing

Simon Horman (1):
ravb: Avoid unsupported internal delay mode for R-Car E3/D3

Vladimir Zapolskiy (2):
gpio: rcar: reference device instead of platform device
gpio: rcar: select General Output Register to set output states

Wolfram Sang (1):
dmaengine: rcar-dmac: set scatter/gather max segment size

.../devicetree/bindings/dma/renesas,usb-dmac.txt | 1 +
.../devicetree/bindings/net/can/rcar_can.txt | 9 +-
.../devicetree/bindings/phy/rcar-gen3-phy-usb3.txt | 10 +-
.../bindings/thermal/rcar-gen3-thermal.txt | 1 +
.../devicetree/bindings/usb/renesas_usbhs.txt | 3 +-
Documentation/devicetree/bindings/usb/usb-xhci.txt | 5 +-
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 1695
++++++++++++++++++++
drivers/clk/renesas/renesas-cpg-mssr.c | 12 +-
drivers/dma/sh/rcar-dmac.c | 7 +-
drivers/gpio/gpio-rcar.c | 38 +-
drivers/mmc/host/renesas_sdhi_internal_dmac.c | 8 +
drivers/net/ethernet/renesas/ravb.h | 6 +-
drivers/net/ethernet/renesas/ravb_main.c | 158 +-
drivers/soc/renesas/rcar-sysc.c | 65 +-
drivers/spi/spi-sh-msiof.c | 4 +-
drivers/thermal/rcar_gen3_thermal.c | 1 +
drivers/tty/serial/sh-sci.c | 47 +-
17 files changed, 1911 insertions(+), 159 deletions(-) create mode
100644 arch/arm64/boot/dts/renesas/r8a774a1.dtsi

--
2.7.4

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: CIP IRC weekly meeting today

SZ Lin (林上智) <SZ.Lin@...>
 

Hi Kudo-san,

 

Noted, thank you for your heads up.

 

SZ

 

From: masashi.kudo@... <masashi.kudo@...>
Sent: Thursday, August 29, 2019 10:51 AM
To: SZ Lin (
林上智) <SZ.Lin@...>
Cc: cip-dev@...
Subject: Re: [cip-dev] CIP IRC weekly meeting today

 

Hello, SZ-san, All,

 

Cybertrust has some proposal to the CIP kernel team.

I would appreciate it if you can add "Cybertrust Proposal" to the agenda.

 

Best regards,

--

M. Kudo

Cybertrust Japan Co., Ltd.

 

2019829() 10:31 SZ Lin (林上智) <SZ.Lin@...>:

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=8&day29&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=24

US-West US-East   UK     DE     TW     JP
02:00    05:00   10:00   11:00   17:00   18:00

Channel:
* irc:chat.freenode.net:6667/cip

Agenda:

* Action item
1. Provide the cases to cip-testing to build up the test environment - Iwamatsu-san

2. Ask cip-dev which configurations need testing - patersonc

3. Test LTS (pre)releases directly – patersonc

4. Discuss and make a decision on default compiler's options - kernel team

5. Look for the new maintainer of CIP security tracker – kernel team

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,

SZ Lin, Moxa.
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: CIP IRC weekly meeting today

masashi.kudo@...
 

Hello, SZ-san, All,

Cybertrust has some proposal to the CIP kernel team.
I would appreciate it if you can add "Cybertrust Proposal" to the agenda.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.

2019年8月29日(木) 10:31 SZ Lin (林上智) <SZ.Lin@...>:

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=8&day29&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=24

US-West US-East   UK     DE     TW     JP
02:00    05:00   10:00   11:00   17:00   18:00

Channel:
* irc:chat.freenode.net:6667/cip

Agenda:

* Action item
1. Provide the cases to cip-testing to build up the test environment - Iwamatsu-san

2. Ask cip-dev which configurations need testing - patersonc

3. Test LTS (pre)releases directly – patersonc

4. Discuss and make a decision on default compiler's options - kernel team

5. Look for the new maintainer of CIP security tracker – kernel team

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* AOB

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,

SZ Lin, Moxa.
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev

6561 - 6580 of 9641