[PATCH AUTOSEL 6.18-6.1] pinctrl: renesas: rzv2m: Use -ENOTSUPP instead of -EOPNOTSUPP

[Sasha Levin <sashal@kernel.org>]

From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>

[ Upstream commit 01f94d53947df35ba77cdb3992a4e3ef9d9dc1ad ]

The pinctrl and GPIO core code make exceptions for the -ENOTSUPP error
code. One such example is gpio_set_config_with_argument_optional(), which
returns success when gpio_set_config_with_argument() returns -ENOTSUPP, but
reports failure for all other error codes.

Returning -EOPNOTSUPP from the pinctrl driver on the unsupported pinctrl
operation may lead to boot failures when pinctrl drivers implements
struct gpio_chip::set_config, the system uses GPIO hogs, and the
struct gpio_chip::set_config implementation returns -EOPNOTSUPP for the
unsupported operations.

Currently, the driver does not implement struct gpio_chip::set_config().
To avoid future failures, return -ENOTSUPP from
rzv2m_pinctrl_pinconf_set().

rzv2m_pinctrl_pinconf_group_get() is used when dumping pinctrl
configuration. pinconf_generic_dump_one(), which calls it, makes
exceptions for the -EINVAL and -ENOTSUPP error codes. The documentation
for struct pinconf_ops::pin_config_group_get states that it "should
return -ENOTSUPP and -EINVAL using the same rules as pin_config_get()".
The documentation for struct pinconf_ops::pin_config_get states:

"get the config of a certain pin, if the requested config is not available
on this controller this should return -ENOTSUPP and if it is available but
disabled it should return -EINVAL".

Return -ENOTSUPP for the unsupported pinctrl operation.

Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260522105717.1727837-1-claudiu.beznea@kernel.org
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `pinctrl: renesas: rzv2m: Use -ENOTSUPP
instead of -EOPNOTSUPP`

**Local tree:** Linux **6.18.44** (`git describe HEAD` → `v6.18.44`,
`make kernelversion` → `6.18.44`)

**Upstream commit:** `01f94d53947df` (on `master`; **not** in this
6.18.44 checkout)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[pinctrl: renesas: rzv2m]` — action: **Use** (correctness
fix) — return the proper `-ENOTSUPP` errno instead of `-EOPNOTSUPP` for
unsupported pinconf operations.

### Step 1.2: Tags
**Record:**
- **Suggested-by:** Geert Uytterhoeven (maintainer suggested the fix)
- **Signed-off-by:** Claudiu Beznea (author), Geert Uytterhoeven
  (committer on master)
- **Reviewed-by:** Geert Uytterhoeven (subsystem maintainer)
- **Link:** https://patch.msgid.link/20260522105717.1727837-1-
  claudiu.beznea@kernel.org
- **No** Fixes:, Reported-by:, Tested-by:, Cc: stable@vger.kernel.org
  (absence of Cc: stable is expected per review instructions)
- **Notable:** Maintainer-reviewed, maintainer-suggested; no syzbot or
  user bug reports

### Step 1.3: Body analysis
**Record:**
- **Bug:** Driver returns `-EOPNOTSUPP` where pinctrl/GPIO core expects
  `-ENOTSUPP` for “unsupported configuration”
- **Symptoms:**
  - Potential **boot failure** if `gpio_chip::set_config` is added and
    GPIO hogs trigger optional config paths
    (`gpio_set_config_with_argument_optional()` treats only `-ENOTSUPP`
    as benign)
  - **Incorrect debugfs dumps**: `pinconf_generic_dump_one()` treats
    `-ENOTSUPP` and `-EINVAL` as legal; `-EOPNOTSUPP` prints `"ERROR
    READING CONFIG SETTING"`
- **Root cause:** Violation of documented `pinconf_ops` API contract
  (`include/linux/pinctrl/pinconf.h`)
- **Version info:** None in message; driver has existed since 2022

### Step 1.4: Hidden bug fix?
**Record:** **Yes.** Despite neutral “Use X instead of Y” wording, this
fixes a real API-contract bug with concrete debugfs impact and a
documented boot-failure class for GPIO hog + `set_config` paths.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/pinctrl/renesas/pinctrl-rzv2m.c` — 2 lines changed
  (+2/-2)
- **Functions:** `rzv2m_pinctrl_pinconf_set()`,
  `rzv2m_pinctrl_pinconf_group_get()`
- **Scope:** Single-file, surgical fix

### Step 2.2: Code flow per hunk

**Hunk 1 — `rzv2m_pinctrl_pinconf_set()` default case:**
- **Before:** Unknown `PIN_CONFIG_*` param → `-EOPNOTSUPP`
- **After:** → `-ENOTSUPP`
- **Path:** DT pinconf apply / explicit pin configuration for
  unsupported parameters

**Hunk 2 — `rzv2m_pinctrl_pinconf_group_get()` mismatch check:**
- **Before:** Pins in group disagree on config value → `-EOPNOTSUPP`
- **After:** → `-ENOTSUPP`
- **Path:** `pinconf_generic_dump_one()` → `pin_config_group_get()`
  during debugfs pinconf dumps

### Step 2.3: Bug mechanism
**Record:** **Logic / API correctness fix (category g).** Core
GPIO/pinconf code special-cases `-ENOTSUPP` but not `-EOPNOTSUPP`. The
driver already returns `-ENOTSUPP` correctly in
`rzv2m_pinctrl_pinconf_get()` (line 548); these two sites were
inconsistent.

### Step 2.4: Fix quality
**Record:** Obviously correct, minimal, matches kernel-wide convention
and sibling `rzg2l` fix. Regression risk: **very low** (only changes
error codes on unsupported/mismatched-config paths).

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** `-EOPNOTSUPP` in `pinconf_set` default case introduced in
`92a9b82525761` (“Add RZ/V2M pin and gpio controller driver”, June
2022). Present in this 6.18.44 tree.

### Step 3.2: Fixes: tag
**Record:** N/A — no Fixes: tag in commit message.

### Step 3.3: Related file history
**Record:**
- Identical fix for `rzg2l` already backported to **this tree**:
  `6876f767b0490` (upstream `c1492da3939c`)
- Related but separate: `ec642ab9b76f8` (type fix in
  `pin_config_group_get`) is on `master` but **not** in 6.18.44 — not a
  prerequisite for this 2-line errno change
- Standalone single-patch series (v1 only per `b4 dig -a`)

### Step 3.4: Author context
**Record:** Claudiu Beznea is an active Renesas pinctrl contributor;
Geert Uytterhoeven is the Renesas maintainer who committed and reviewed.

### Step 3.5: Dependencies
**Record:** **None.** Patch applies cleanly (`git apply --check` → exit
0). Does not assume code absent from 6.18.44.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:**
- **URL:** https://patch.msgid.link/20260522105717.1727837-1-
  claudiu.beznea@kernel.org
- **Series:** v1 only (no revisions)
- **Review:** Geert Uytterhoeven Reviewed-by + “will queue in renesas-
  devel for v7.2”
- **No** NAKs, no explicit stable nomination in thread
- Lore web fetch blocked by bot protection; content obtained via `b4 dig
  -m`

### Step 4.2: Reviewers
**Record:** CC’d: `geert+renesas@glider.be`, `linusw@kernel.org`,
`brgl@kernel.org`, `linux-renesas-soc@`, `linux-gpio@`, `linux-kernel@`
— appropriate maintainer coverage.

### Step 4.3: Bug report
**Record:** N/A — no external bug report; preventive/correctness fix
identified by maintainer (Suggested-by Geert).

### Step 4.4: Related patches
**Record:** Part of a Renesas-wide errno cleanup; `rzg2l` variant
already in this stable tree.

### Step 4.5: Stable list
**Record:** Not searched (lore blocked); `rzg2l` sibling carried `Cc:
stable@vger.kernel.org` and was backported here.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `rzv2m_pinctrl_pinconf_set`,
`rzv2m_pinctrl_pinconf_group_get`

### Step 5.2: Callers
**Record:**
- `pinconf_set` → `pinconf_apply_setting()` during pinctrl DT binding
  (boot)
- `pinconf_group_get` → `pin_config_group_get()` →
  `pinconf_generic_dump_one()` (debugfs via
  `pinconf_generic_dump_config`; driver sets `is_generic = true`)

### Step 5.3: Callees
**Record:** `rzv2m_pinctrl_pinconf_get()` (group_get),
`pinconf_to_config_param()` (set)

### Step 5.4: Reachability
**Record:**
- **Boot:** `pinconf_set` path reachable on RZ/V2M boot with unsupported
  DT pinconf properties (both errnos fail equally today via
  `pinconf_apply_setting`)
- **GPIO hog boot failure:** **Not currently reachable** —
  `rzv2m_gpio_register()` does not set `chip->set_config`;
  `gpio_do_set_config()` returns `-ENOTSUPP` when `set_config` is NULL
- **Debugfs:** `pinconf_group_get` path **is reachable** on RZ/V2M when
  dumping pinconf; wrong errno causes spurious error strings
- **RZ/V2M EVK** (`r9a09g011-v2mevk2.dts`): no `gpio-hog` nodes found

### Step 5.5: Similar patterns
**Record:** `rzv2m_pinctrl_pinconf_get()` already uses `-ENOTSUPP` (line
548). `rzg2l` fix already backported in this tree. Kernel-wide
convention: pinctrl drivers return `-ENOTSUPP` for unsupported configs.

---

## PHASE 6: CROSS-REFERENCE WITH LOCAL TREE (6.18.44)

### Step 6.1: Buggy code exists?
**Record:** **Yes.** Lines 664 and 713 in `pinctrl-rzv2m.c` still return
`-EOPNOTSUPP`. Driver present since v6.x (2022).

### Step 6.2: Backport complications
**Record:** **Clean apply** — verified with `git show 01f94d53947df |
git apply --check`.

### Step 6.3: Related fixes already present?
**Record:** `rzg2l` errno fix (`6876f767b0490`) is in this tree; `rzv2m`
fix is **not** yet applied.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem / criticality
**Record:** `drivers/pinctrl/renesas` — **PERIPHERAL** (RZ/V2M /
`ARCH_R9A09G011` platform-specific), but uses generic pinconf
infrastructure shared with GPIO core.

### Step 7.2: Activity
**Record:** Active — recent rzv2m fixes in this tree (NULL deref,
of_node_put, GPIO callback updates).

---

## PHASE 8: IMPACT AND RISK

### Step 8.1: Who is affected
**Record:** RZ/V2M (`CONFIG_PINCTRL_RZV2M`) users — embedded/industrial
platforms. Not universal.

### Step 8.2: Trigger conditions
**Record:**
- **Current:** Debugfs pinconf dump with heterogeneous pin groups; API
  misuse if unsupported pinconf applied via DT
- **Future:** `set_config` + GPIO hogs with optional bias/config flags
- **Likelihood today:** Low for boot (no `set_config`, no gpio-hogs on
  rzv2m boards); moderate for debugfs correctness

### Step 8.3: Failure mode severity
**Record:**
- Boot failure (future `set_config` path): **CRITICAL** if triggered
- Debugfs spurious errors today: **LOW**
- API contract violation: correctness issue, not crash by itself

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Medium — aligns with already-backported `rzg2l` fix,
  fixes debugfs behavior, prevents future boot regression, correct per
  `pinconf.h`
- **Risk:** Very low — 2 errno changes on error paths only
- **Ratio:** Favorable

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Identical `rzg2l` fix already accepted into **this** 6.18.44 tree
- Documented API contract (`pinconf.h` requires `-ENOTSUPP`)
- Internal driver inconsistency (`pinconf_get` already uses `-ENOTSUPP`)
- Real debugfs impact via `pinconf_generic_dump_one()`
- Preventive boot-failure fix when `set_config` is added
- 2-line change, applies cleanly, maintainer-reviewed
- Bug present since driver introduction (2022)

**AGAINST backport:**
- No current boot failure (no `set_config`, no gpio-hogs on rzv2m
  boards)
- Platform-specific, limited user base
- No user bug report or syzbot finding
- “Important issue” threshold is borderline for *current* runtime impact

**Unresolved:** None material to the decision.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — errno swap matches API docs
   and `rzg2l` precedent; Reviewed-by maintainer (no Tested-by)
2. Fixes a real bug? **PASS** — API contract violation with verified
   debugfs impact; boot failure class documented
3. Important issue? **PASS (borderline)** — not crashing today, but same
   class of fix already deemed stable-worthy for `rzg2l` in this tree;
   future boot failure is serious
4. Small and contained? **PASS** — 2 lines, 1 file
5. No new features/APIs? **PASS**
6. Can apply to local tree? **PASS** — clean apply verified

### Step 9.3: Exception categories
**Record:** None (not device ID, quirk, DT, build, or docs-only).

### Step 9.4: Decision rationale

The strongest argument is **consistency within this stable tree**:
maintainers already backported the identical `rzg2l` errno fix
(`6876f767b0490`) to 6.18.44. The `rzv2m` driver has the same bug
pattern, the same author/reviewer, and the same API-contract violation.
While current boot impact is limited (no `gpio_chip::set_config`, no
gpio-hogs on RZ/V2M boards), the `pinconf_group_get` path already
produces incorrect debugfs behavior, and the fix is trivial with
negligible regression risk.

---

## Verification

- **[Phase 1]** Parsed commit message and tags from user query + `git
  show 01f94d53947df`
- **[Phase 2]** Diff analysis: 2 errno changes in `pinctrl-rzv2m.c`;
  read surrounding code at lines 530–744
- **[Phase 3]** `git describe HEAD` → v6.18.44; `git blame` → buggy
  lines from `92a9b82525761` (2022)
- **[Phase 3]** `git log -- drivers/pinctrl/renesas/pinctrl-rzv2m.c` —
  driver history reviewed
- **[Phase 3]** Found `6876f767b0490` (rzg2l sibling fix) already in
  HEAD
- **[Phase 3]** `ec642ab9b76f8` NOT in HEAD — separate type fix, not a
  prerequisite
- **[Phase 4]** `b4 dig -c 01f94d53947df` → lore URL; `b4 dig -a` → v1
  only; `b4 dig -w` → maintainers CC'd
- **[Phase 4]** `b4 dig -m /tmp/rzv2m_enotsupp.mbox` — Geert Reviewed-
  by, no NAKs
- **[Phase 5]** Read `gpio_set_config_with_argument_optional()` in
  `gpiolib.c:2694–2714` — only `-ENOTSUPP` treated as success
- **[Phase 5]** Read `pinconf_generic_dump_one()` in `pinconf-
  generic.c:59–84` — `-ENOTSUPP`/`-EINVAL` skipped
- **[Phase 5]** Read `pinconf.h:24–29` — API documents `-ENOTSUPP`
- **[Phase 5]** Verified `rzv2m` has no `chip->set_config` in
  `rzv2m_gpio_register()` (lines 953–960)
- **[Phase 5]** Grep: no gpio-hogs in `r9a09g011-v2mevk2.dts`
- **[Phase 6]** Grep confirms `-EOPNOTSUPP` still at lines 664, 713 in
  HEAD
- **[Phase 6]** `git show 01f94d53947df | git apply --check` → applies
  cleanly
- **[Phase 6]** `master` has fix at lines 664, 714; HEAD does not

**YES**The background git searches finished successfully and match what
the analysis already used:

- The **rzv2m** fix is upstream commit `01f94d53947df` on `master`; it
  is **not** in this **6.18.44** tree yet (lines 664 and 713 still
  return `-EOPNOTSUPP`).
- The sibling **rzg2l** fix (`6876f767b0490`) **is** already backported
  here.

**Verdict for 6.18.44: YES** — same 2-line errno correction, applies
cleanly, and consistent with the rzg2l backport already in this tree.

 drivers/pinctrl/renesas/pinctrl-rzv2m.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/renesas/pinctrl-rzv2m.c b/drivers/pinctrl/renesas/pinctrl-rzv2m.c
index dce68f93d2d57..e08f24d5a89f5 100644
--- a/drivers/pinctrl/renesas/pinctrl-rzv2m.c
+++ b/drivers/pinctrl/renesas/pinctrl-rzv2m.c
@@ -661,7 +661,7 @@ static int rzv2m_pinctrl_pinconf_set(struct pinctrl_dev *pctldev,
 		}
 
 		default:
-			return -EOPNOTSUPP;
+			return -ENOTSUPP;
 		}
 	}
 
@@ -710,7 +710,7 @@ static int rzv2m_pinctrl_pinconf_group_get(struct pinctrl_dev *pctldev,
 
 		/* Check config matches previous pins */
 		if (i && prev_config != *config)
-			return -EOPNOTSUPP;
+			return -ENOTSUPP;
 
 		prev_config = *config;
 	}
-- 
2.53.0