[PATCH 000/102] Convert drivers to explicit reset API

[PATCH 000/102] Convert drivers to explicit reset API

[Philipp Zabel]

The reset control API has two modes: exclusive access, where the driver
expects to have full and immediate control over the state of the reset
line, and shared (clock-like) access, where drivers only request reset
deassertion while active, but don't care about the state of the reset line
while inactive.

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior.

This series converts all drivers that currently implicitly request
exclusive reset controls to the corresponding explicit API call. It is,
for the most part, generated from the following semantic patch:

@@
expression rstc, dev, id;
@@
-rstc = reset_control_get(dev, id);
+rstc = reset_control_get_exclusive(dev, id);
@@
expression rstc, dev, id;
@@
-rstc = reset_control_get_optional(dev, id);
+rstc = reset_control_get_optional_exclusive(dev, id);
@@
expression rstc, node, id;
@@
-rstc = of_reset_control_get(node, id);
+rstc = of_reset_control_get_exclusive(node, id);
@@
expression rstc, node, index;
@@
-rstc = of_reset_control_get_by_index(node, index);
+rstc = of_reset_control_get_exclusive_by_index(node, index);
@@
expression rstc, dev, id;
@@
-rstc = devm_reset_control_get(dev, id);
+rstc = devm_reset_control_get_exclusive(dev, id);
@@
expression rstc, dev, id;
@@
-rstc = devm_reset_control_get_optional(dev, id);
+rstc = devm_reset_control_get_optional_exclusive(dev, id);
@@
expression rstc, dev, index;
@@
-rstc = devm_reset_control_get_by_index(dev, index);
+rstc = devm_reset_control_get_exclusive_by_index(dev, index);

After all driver patches are applied, the temporary transition helpers
can be removed.

regards
Philipp

Philipp Zabel (102):
  ARM: rockchip: explicitly request exclusive reset control
  ARM: socfpga: explicitly request exclusive reset control
  MIPS: pci-mt7620: explicitly request exclusive reset control
  ahci: st: explicitly request exclusive reset control
  ata: sata_gemini: explicitly request exclusive reset control
  ata: ahci_tegra: explicitly request exclusive reset control
  bus: sunxi-rsb: explicitly request exclusive reset control
  bus: tegra-gmi: explicitly request exclusive reset control
  clk: sunxi: explicitly request exclusive reset control
  clk: tegra: explicitly request exclusive reset control
  clocksource/drivers/timer-stm32: explicitly request exclusive reset
    control
  clocksource/drivers/sun5i: explicitly request exclusive reset control
  crypto: rockchip: explicitly request exclusive reset control
  crypto: sun4i-ss - request exclusive reset control
  PM / devfreq: tegra: explicitly request exclusive reset control
  dmaengine: stm32-dma: explicitly request exclusive reset control
  dmaengine: sun6i: explicitly request exclusive reset control
  dmaengine: tegra-apb: explicitly request exclusive reset control
  drm: kirin: explicitly request exclusive reset control
  drm/nouveau/tegra: explicitly request exclusive reset control
  drm/rockchip: explicitly request exclusive reset control
  drm/sti: explicitly request exclusive reset control
  drm/stm: explicitly request exclusive reset control
  drm/sun4i: explicitly request exclusive reset control
  drm/tegra: explicitly request exclusive reset control
  gpu: host1x: explicitly request exclusive reset control
  i2c: mv64xxx: explicitly request exclusive reset control
  i2c: stm32f4: explicitly request exclusive reset control
  i2c: sun6i-pw2i: explicitly request exclusive reset control
  i2c: tegra: explicitly request exclusive reset control
  iio: adc: rockchip_saradc: explicitly request exclusive reset control
  iio: dac: stm32-dac-core: explicitly request exclusive reset control
  Input: tegra-kbc - request exclusive reset control
  coda: explicitly request exclusive reset control
  st-rc: explicitly request exclusive reset control
  stm32-dcmi: explicitly request exclusive reset control
  rc: sunxi-cir: explicitly request exclusive reset control
  mmc: dw_mmc: explicitly request exclusive reset control
  mmc: sdhci-st: explicitly request exclusive reset control
  mmc: sunxi: explicitly request exclusive reset control
  mmc: tegra: explicitly request exclusive reset control
  mtd: nand: sunxi: explicitly request exclusive reset control
  mtd: spi-nor: stm32-quadspi: explicitly request exclusive reset
    control
  net: dsa: mt7530: explicitly request exclusive reset control
  net: ethernet: hisi_femac: explicitly request exclusive reset control
  net: ethernet: hix5hd2_gmac: explicitly request exclusive reset
    control
  net: stmmac: explicitly request exclusive reset control
  net: stmmac: dwc-qos: explicitly request exclusive reset control
  ath10k: explicitly request exclusive reset control
  nvmem: lpc18xx-eeprom: explicitly request exclusive reset control
  PCI: dwc: pcie-qcom: explicitly request exclusive reset control
  PCI: imx6: explicitly request exclusive reset control
  PCI: tegra: explicitly request exclusive reset control
  PCI: rockchip: explicitly request exclusive reset control
  phy: berlin-usb: explicitly request exclusive reset control
  PCI: mediatek: explicitly request exclusive reset control
  phy: qcom-usb-hs: explicitly request exclusive reset control
  phy: rockchip-pcie: explicitly request exclusive reset control
  phy: rockchip-typec: explicitly request exclusive reset control
  phy: rockchip-usb: explicitly request exclusive reset control
  phy: sun4i-usb: explicitly request exclusive reset control
  phy: sun9i-usb: explicitly request exclusive reset control
  phy: tegra: explicitly request exclusive reset control
  phy: qcom-qmp: explicitly request exclusive reset control
  phy: qcom-qusb2: explicitly request exclusive reset control
  pinctrl: stm32: explicitly request exclusive reset control
  pinctrl: sunxi: explicitly request exclusive reset control
  pinctrl: tegra: explicitly request exclusive reset control
  pwm: hibvt: explicitly request exclusive reset control
  pwm: tegra: explicitly request exclusive reset control
  remoteproc/keystone: explicitly request exclusive reset control
  remoteproc: qcom: explicitly request exclusive reset control
  remoteproc: st: explicitly request exclusive reset control
  soc: mediatek: PMIC wrap: explicitly request exclusive reset control
  soc/tegra: pmc: explicitly request exclusive reset control
  spi: stm32: explicitly request exclusive reset control
  spi: sun6i: explicitly request exclusive reset control
  spi: tegra20-slink: explicitly request exclusive reset control
  spi: tegra114: explicitly request exclusive reset control
  spi: tegra20-sflash: explicitly request exclusive reset control
  staging: nvec: explicitly request exclusive reset control
  thermal: rockchip: explicitly request exclusive reset control
  thermal: tegra: explicitly request exclusive reset control
  serial: 8250_dw: explicitly request exclusive reset control
  serial: tegra: explicitly request exclusive reset control
  usb: chipidea: msm: explicitly request exclusive reset control
  usb: dwc2: explicitly request exclusive reset control
  usb: host: ehci-tegra: explicitly request exclusive reset control
  usb: host: xhci-tegra: explicitly request exclusive reset control
  usb: musb: sunxi: explicitly request exclusive reset control
  usb: phy: msm: explicitly request exclusive reset control
  usb: phy: qcom-8x16-usb: explicitly request exclusive reset control
  watchdog: asm9260: explicitly request exclusive reset control
  watchdog: mt7621: explicitly request exclusive reset control
  watchdog: rt2880: explicitly request exclusive reset control
  watchdog: zx2967: explicitly request exclusive reset control
  ASoC: img: explicitly request exclusive reset control
  ASoC: stm32: explicitly request exclusive reset control
  ASoC: sun4i: explicitly request exclusive reset control
  ASoC: tegra: explicitly request exclusive reset control
  Documentation: devres: add explicit exclusive/shared reset control
    request calls
  reset: finish transition to explicit exclusive reset control requests

 Documentation/driver-model/devres.txt              |  7 ++-
 arch/arm/mach-rockchip/platsmp.c                   |  2 +-
 arch/mips/pci/pci-mt7620.c                         |  2 +-
 drivers/ata/ahci_st.c                              |  6 +--
 drivers/ata/ahci_tegra.c                           |  8 ++--
 drivers/ata/sata_gemini.c                          |  4 +-
 drivers/bus/sunxi-rsb.c                            |  2 +-
 drivers/bus/tegra-gmi.c                            |  2 +-
 drivers/clk/sunxi/clk-sun9i-mmc.c                  |  2 +-
 drivers/clk/tegra/clk-dfll.c                       |  2 +-
 drivers/clocksource/timer-stm32.c                  |  2 +-
 drivers/clocksource/timer-sun5i.c                  |  2 +-
 drivers/crypto/rockchip/rk3288_crypto.c            |  2 +-
 drivers/crypto/sunxi-ss/sun4i-ss-core.c            |  3 +-
 drivers/devfreq/tegra-devfreq.c                    |  2 +-
 drivers/dma/stm32-dma.c                            |  2 +-
 drivers/dma/sun6i-dma.c                            |  2 +-
 drivers/dma/tegra20-apb-dma.c                      |  2 +-
 drivers/fpga/altera-hps2fpga.c                     |  3 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c    |  2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c |  2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c    |  2 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c             |  8 ++--
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c             |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c        |  4 +-
 drivers/gpu/drm/sti/sti_hdmi.c                     |  2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c                    |  2 +-
 drivers/gpu/drm/sti/sti_tvout.c                    |  2 +-
 drivers/gpu/drm/stm/ltdc.c                         |  2 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c              |  4 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c                 |  2 +-
 drivers/gpu/drm/sun4i/sun4i_tv.c                   |  2 +-
 drivers/gpu/drm/sun4i/sun6i_drc.c                  |  2 +-
 drivers/gpu/drm/sun4i/sun8i_mixer.c                |  2 +-
 drivers/gpu/drm/tegra/dc.c                         |  2 +-
 drivers/gpu/drm/tegra/dpaux.c                      |  3 +-
 drivers/gpu/drm/tegra/dsi.c                        |  2 +-
 drivers/gpu/drm/tegra/gr3d.c                       |  6 +--
 drivers/gpu/drm/tegra/hdmi.c                       |  2 +-
 drivers/gpu/drm/tegra/sor.c                        |  2 +-
 drivers/gpu/host1x/dev.c                           |  2 +-
 drivers/i2c/busses/i2c-mv64xxx.c                   |  2 +-
 drivers/i2c/busses/i2c-stm32f4.c                   |  2 +-
 drivers/i2c/busses/i2c-sun6i-p2wi.c                |  2 +-
 drivers/i2c/busses/i2c-tegra.c                     |  2 +-
 drivers/iio/adc/rockchip_saradc.c                  |  3 +-
 drivers/iio/dac/stm32-dac-core.c                   |  2 +-
 drivers/input/keyboard/tegra-kbc.c                 |  2 +-
 drivers/media/platform/coda/coda-common.c          |  3 +-
 drivers/media/platform/stm32/stm32-dcmi.c          |  2 +-
 drivers/media/rc/st_rc.c                           |  2 +-
 drivers/media/rc/sunxi-cir.c                       |  2 +-
 drivers/mmc/host/dw_mmc.c                          |  2 +-
 drivers/mmc/host/sdhci-st.c                        |  2 +-
 drivers/mmc/host/sdhci-tegra.c                     |  3 +-
 drivers/mmc/host/sunxi-mmc.c                       |  3 +-
 drivers/mtd/nand/sunxi_nand.c                      |  2 +-
 drivers/mtd/spi-nor/stm32-quadspi.c                |  2 +-
 drivers/net/dsa/mt7530.c                           |  3 +-
 drivers/net/ethernet/hisilicon/hisi_femac.c        |  4 +-
 drivers/net/ethernet/hisilicon/hix5hd2_gmac.c      |  6 +--
 .../ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c    |  2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c  |  3 +-
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |  4 +-
 drivers/net/wireless/ath/ath10k/ahb.c              | 15 ++++---
 drivers/nvmem/lpc18xx_eeprom.c                     |  2 +-
 drivers/pci/dwc/pci-imx6.c                         |  7 +--
 drivers/pci/dwc/pcie-qcom.c                        | 40 +++++++++--------
 drivers/pci/host/pci-tegra.c                       |  6 +--
 drivers/pci/host/pcie-mediatek.c                   |  2 +-
 drivers/pci/host/pcie-rockchip.c                   | 15 ++++---
 drivers/phy/allwinner/phy-sun4i-usb.c              |  2 +-
 drivers/phy/allwinner/phy-sun9i-usb.c              |  4 +-
 drivers/phy/marvell/phy-berlin-usb.c               |  2 +-
 drivers/phy/qualcomm/phy-qcom-qmp.c                |  4 +-
 drivers/phy/qualcomm/phy-qcom-qusb2.c              |  3 +-
 drivers/phy/qualcomm/phy-qcom-usb-hs.c             |  3 +-
 drivers/phy/rockchip/phy-rockchip-pcie.c           |  2 +-
 drivers/phy/rockchip/phy-rockchip-typec.c          |  6 +--
 drivers/phy/rockchip/phy-rockchip-usb.c            |  2 +-
 drivers/phy/tegra/xusb-tegra210.c                  |  4 +-
 drivers/phy/tegra/xusb.c                           |  2 +-
 drivers/pinctrl/stm32/pinctrl-stm32.c              |  2 +-
 drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c        |  2 +-
 drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c        |  2 +-
 drivers/pinctrl/tegra/pinctrl-tegra-xusb.c         |  2 +-
 drivers/pwm/pwm-hibvt.c                            |  2 +-
 drivers/pwm/pwm-tegra.c                            |  2 +-
 drivers/remoteproc/keystone_remoteproc.c           |  2 +-
 drivers/remoteproc/qcom_q6v5_pil.c                 |  3 +-
 drivers/remoteproc/st_remoteproc.c                 |  6 ++-
 drivers/reset/core.c                               |  2 +-
 drivers/soc/mediatek/mtk-pmic-wrap.c               |  5 ++-
 drivers/soc/tegra/pmc.c                            |  2 +-
 drivers/spi/spi-stm32.c                            |  2 +-
 drivers/spi/spi-sun6i.c                            |  2 +-
 drivers/spi/spi-tegra114.c                         |  2 +-
 drivers/spi/spi-tegra20-sflash.c                   |  2 +-
 drivers/spi/spi-tegra20-slink.c                    |  2 +-
 drivers/staging/nvec/nvec.c                        |  2 +-
 drivers/thermal/rockchip_thermal.c                 |  3 +-
 drivers/thermal/tegra/soctherm.c                   |  3 +-
 drivers/tty/serial/8250/8250_dw.c                  |  2 +-
 drivers/tty/serial/serial-tegra.c                  |  2 +-
 drivers/usb/chipidea/ci_hdrc_msm.c                 |  2 +-
 drivers/usb/dwc2/platform.c                        |  3 +-
 drivers/usb/host/ehci-tegra.c                      |  5 ++-
 drivers/usb/host/xhci-tegra.c                      |  6 ++-
 drivers/usb/musb/sunxi.c                           |  2 +-
 drivers/usb/phy/phy-msm-usb.c                      |  4 +-
 drivers/usb/phy/phy-qcom-8x16-usb.c                |  2 +-
 drivers/watchdog/asm9260_wdt.c                     |  2 +-
 drivers/watchdog/mt7621_wdt.c                      |  2 +-
 drivers/watchdog/rt2880_wdt.c                      |  2 +-
 drivers/watchdog/zx2967_wdt.c                      |  2 +-
 include/linux/reset.h                              | 50 ----------------------
 sound/soc/img/img-i2s-in.c                         |  2 +-
 sound/soc/img/img-i2s-out.c                        |  2 +-
 sound/soc/img/img-parallel-out.c                   |  2 +-
 sound/soc/img/img-spdif-in.c                       |  2 +-
 sound/soc/img/img-spdif-out.c                      |  2 +-
 sound/soc/stm/stm32_i2s.c                          |  2 +-
 sound/soc/stm/stm32_sai.c                          |  2 +-
 sound/soc/stm/stm32_spdifrx.c                      |  2 +-
 sound/soc/sunxi/sun4i-codec.c                      |  3 +-
 sound/soc/sunxi/sun4i-i2s.c                        |  2 +-
 sound/soc/sunxi/sun4i-spdif.c                      |  3 +-
 sound/soc/tegra/tegra30_ahub.c                     |  4 +-
 128 files changed, 226 insertions(+), 235 deletions(-)

-- 
2.11.0

Cc: "David S. Miller" <davem@davemloft.net>
Cc: "Emilio López" <emilio@elopez.com.ar>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Alan Tull <atull@kernel.org>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Bin Liu <b-liu@ti.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Chen Feng <puck.chen@hisilicon.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Corentin Labbe <clabbe.montjoie@gmail.com>
Cc: Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: David Airlie <airlied@linux.ie>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Joachim Eastwood <manabian@gmail.com>
Cc: John Youn <johnyoun@synopsys.com>
Cc: Jon Hunter <jonathanh@nvidia.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Marc Dietrich <marvin24@gmx.de>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Moritz Fischer <moritz.fischer@ettus.com>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Peter Chen <Peter.Chen@nxp.com>
Cc: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Philippe Cornu <philippe.cornu@st.com>
Cc: Prashant Gaikwad <pgaikwad@nvidia.com>
Cc: Rakesh Iyer <riyer@nvidia.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Richard Zhu <hongxing.zhu@nxp.com>
Cc: Rongrong Zou <zourongrong@gmail.com>
Cc: Ryder Lee <ryder.lee@mediatek.com>
Cc: Salil Mehta <salil.mehta@huawei.com>
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Stanimir Varbanov <svarbanov@mm-sol.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Xinliang Liu <z.liuxinliang@hisilicon.com>
Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com>
Cc: Yannick Fertre <yannick.fertre@st.com>
Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: alsa-devel@alsa-project.org
Cc: ath10k@lists.infradead.org
Cc: devel@driverdev.osuosl.org
Cc: dmaengine@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-fpga@vger.kernel.org
Cc: linux-gpio@vger.kernel.org
Cc: linux-i2c@vger.kernel.org
Cc: linux-ide@vger.kernel.org
Cc: linux-iio@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-mips@linux-mips.org
Cc: linux-mmc@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-pci@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-pwm@vger.kernel.org
Cc: linux-remoteproc@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-serial@vger.kernel.org
Cc: linux-spi@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-watchdog@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: nouveau@lists.freedesktop.org

[PATCH 051/102] PCI: dwc: pcie-qcom: explicitly request exclusive reset control

[Philipp Zabel]

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.

No functional changes.

Cc: Stanimir Varbanov <svarbanov@mm-sol.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 drivers/pci/dwc/pcie-qcom.c | 40 ++++++++++++++++++++++------------------
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
index 68c5f2ab5bc8f..90f7796a7cffe 100644
--- a/drivers/pci/dwc/pcie-qcom.c
+++ b/drivers/pci/dwc/pcie-qcom.c
@@ -212,23 +212,23 @@ static int qcom_pcie_get_resources_v0(struct qcom_pcie *pcie)
 	if (IS_ERR(res->phy_clk))
 		return PTR_ERR(res->phy_clk);
 
-	res->pci_reset = devm_reset_control_get(dev, "pci");
+	res->pci_reset = devm_reset_control_get_exclusive(dev, "pci");
 	if (IS_ERR(res->pci_reset))
 		return PTR_ERR(res->pci_reset);
 
-	res->axi_reset = devm_reset_control_get(dev, "axi");
+	res->axi_reset = devm_reset_control_get_exclusive(dev, "axi");
 	if (IS_ERR(res->axi_reset))
 		return PTR_ERR(res->axi_reset);
 
-	res->ahb_reset = devm_reset_control_get(dev, "ahb");
+	res->ahb_reset = devm_reset_control_get_exclusive(dev, "ahb");
 	if (IS_ERR(res->ahb_reset))
 		return PTR_ERR(res->ahb_reset);
 
-	res->por_reset = devm_reset_control_get(dev, "por");
+	res->por_reset = devm_reset_control_get_exclusive(dev, "por");
 	if (IS_ERR(res->por_reset))
 		return PTR_ERR(res->por_reset);
 
-	res->phy_reset = devm_reset_control_get(dev, "phy");
+	res->phy_reset = devm_reset_control_get_exclusive(dev, "phy");
 	return PTR_ERR_OR_ZERO(res->phy_reset);
 }
 
@@ -393,7 +393,7 @@ static int qcom_pcie_get_resources_v1(struct qcom_pcie *pcie)
 	if (IS_ERR(res->slave_bus))
 		return PTR_ERR(res->slave_bus);
 
-	res->core = devm_reset_control_get(dev, "core");
+	res->core = devm_reset_control_get_exclusive(dev, "core");
 	return PTR_ERR_OR_ZERO(res->core);
 }
 
@@ -623,51 +623,55 @@ static int qcom_pcie_get_resources_v3(struct qcom_pcie *pcie)
 	if (IS_ERR(res->slave_clk))
 		return PTR_ERR(res->slave_clk);
 
-	res->axi_m_reset = devm_reset_control_get(dev, "axi_m");
+	res->axi_m_reset = devm_reset_control_get_exclusive(dev, "axi_m");
 	if (IS_ERR(res->axi_m_reset))
 		return PTR_ERR(res->axi_m_reset);
 
-	res->axi_s_reset = devm_reset_control_get(dev, "axi_s");
+	res->axi_s_reset = devm_reset_control_get_exclusive(dev, "axi_s");
 	if (IS_ERR(res->axi_s_reset))
 		return PTR_ERR(res->axi_s_reset);
 
-	res->pipe_reset = devm_reset_control_get(dev, "pipe");
+	res->pipe_reset = devm_reset_control_get_exclusive(dev, "pipe");
 	if (IS_ERR(res->pipe_reset))
 		return PTR_ERR(res->pipe_reset);
 
-	res->axi_m_vmid_reset = devm_reset_control_get(dev, "axi_m_vmid");
+	res->axi_m_vmid_reset = devm_reset_control_get_exclusive(dev,
+								 "axi_m_vmid");
 	if (IS_ERR(res->axi_m_vmid_reset))
 		return PTR_ERR(res->axi_m_vmid_reset);
 
-	res->axi_s_xpu_reset = devm_reset_control_get(dev, "axi_s_xpu");
+	res->axi_s_xpu_reset = devm_reset_control_get_exclusive(dev,
+								"axi_s_xpu");
 	if (IS_ERR(res->axi_s_xpu_reset))
 		return PTR_ERR(res->axi_s_xpu_reset);
 
-	res->parf_reset = devm_reset_control_get(dev, "parf");
+	res->parf_reset = devm_reset_control_get_exclusive(dev, "parf");
 	if (IS_ERR(res->parf_reset))
 		return PTR_ERR(res->parf_reset);
 
-	res->phy_reset = devm_reset_control_get(dev, "phy");
+	res->phy_reset = devm_reset_control_get_exclusive(dev, "phy");
 	if (IS_ERR(res->phy_reset))
 		return PTR_ERR(res->phy_reset);
 
-	res->axi_m_sticky_reset = devm_reset_control_get(dev, "axi_m_sticky");
+	res->axi_m_sticky_reset = devm_reset_control_get_exclusive(dev,
+								   "axi_m_sticky");
 	if (IS_ERR(res->axi_m_sticky_reset))
 		return PTR_ERR(res->axi_m_sticky_reset);
 
-	res->pipe_sticky_reset = devm_reset_control_get(dev, "pipe_sticky");
+	res->pipe_sticky_reset = devm_reset_control_get_exclusive(dev,
+								  "pipe_sticky");
 	if (IS_ERR(res->pipe_sticky_reset))
 		return PTR_ERR(res->pipe_sticky_reset);
 
-	res->pwr_reset = devm_reset_control_get(dev, "pwr");
+	res->pwr_reset = devm_reset_control_get_exclusive(dev, "pwr");
 	if (IS_ERR(res->pwr_reset))
 		return PTR_ERR(res->pwr_reset);
 
-	res->ahb_reset = devm_reset_control_get(dev, "ahb");
+	res->ahb_reset = devm_reset_control_get_exclusive(dev, "ahb");
 	if (IS_ERR(res->ahb_reset))
 		return PTR_ERR(res->ahb_reset);
 
-	res->phy_ahb_reset = devm_reset_control_get(dev, "phy_ahb");
+	res->phy_ahb_reset = devm_reset_control_get_exclusive(dev, "phy_ahb");
 	if (IS_ERR(res->phy_ahb_reset))
 		return PTR_ERR(res->phy_ahb_reset);
 
-- 
2.11.0

Re: [PATCH 051/102] PCI: dwc: pcie-qcom: explicitly request exclusive reset control

[Bjorn Helgaas]

On Wed, Jul 19, 2017 at 05:25:55PM +0200, Philipp Zabel wrote:
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior. Convert all drivers requesting exclusive resets to the
> explicit API call so the temporary transition helpers can be removed.
> 
> No functional changes.
> 
> Cc: Stanimir Varbanov <svarbanov@mm-sol.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: linux-pci@vger.kernel.org
> Cc: linux-arm-msm@vger.kernel.org
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>

Applied to pci/host-qcom for v4.14, thanks!

Stanimir, holler if you see any issues.

> ---
>  drivers/pci/dwc/pcie-qcom.c | 40 ++++++++++++++++++++++------------------
>  1 file changed, 22 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
> index 68c5f2ab5bc8f..90f7796a7cffe 100644
> --- a/drivers/pci/dwc/pcie-qcom.c
> +++ b/drivers/pci/dwc/pcie-qcom.c
> @@ -212,23 +212,23 @@ static int qcom_pcie_get_resources_v0(struct qcom_pcie *pcie)
>  	if (IS_ERR(res->phy_clk))
>  		return PTR_ERR(res->phy_clk);
>  
> -	res->pci_reset = devm_reset_control_get(dev, "pci");
> +	res->pci_reset = devm_reset_control_get_exclusive(dev, "pci");
>  	if (IS_ERR(res->pci_reset))
>  		return PTR_ERR(res->pci_reset);
>  
> -	res->axi_reset = devm_reset_control_get(dev, "axi");
> +	res->axi_reset = devm_reset_control_get_exclusive(dev, "axi");
>  	if (IS_ERR(res->axi_reset))
>  		return PTR_ERR(res->axi_reset);
>  
> -	res->ahb_reset = devm_reset_control_get(dev, "ahb");
> +	res->ahb_reset = devm_reset_control_get_exclusive(dev, "ahb");
>  	if (IS_ERR(res->ahb_reset))
>  		return PTR_ERR(res->ahb_reset);
>  
> -	res->por_reset = devm_reset_control_get(dev, "por");
> +	res->por_reset = devm_reset_control_get_exclusive(dev, "por");
>  	if (IS_ERR(res->por_reset))
>  		return PTR_ERR(res->por_reset);
>  
> -	res->phy_reset = devm_reset_control_get(dev, "phy");
> +	res->phy_reset = devm_reset_control_get_exclusive(dev, "phy");
>  	return PTR_ERR_OR_ZERO(res->phy_reset);
>  }
>  
> @@ -393,7 +393,7 @@ static int qcom_pcie_get_resources_v1(struct qcom_pcie *pcie)
>  	if (IS_ERR(res->slave_bus))
>  		return PTR_ERR(res->slave_bus);
>  
> -	res->core = devm_reset_control_get(dev, "core");
> +	res->core = devm_reset_control_get_exclusive(dev, "core");
>  	return PTR_ERR_OR_ZERO(res->core);
>  }
>  
> @@ -623,51 +623,55 @@ static int qcom_pcie_get_resources_v3(struct qcom_pcie *pcie)
>  	if (IS_ERR(res->slave_clk))
>  		return PTR_ERR(res->slave_clk);
>  
> -	res->axi_m_reset = devm_reset_control_get(dev, "axi_m");
> +	res->axi_m_reset = devm_reset_control_get_exclusive(dev, "axi_m");
>  	if (IS_ERR(res->axi_m_reset))
>  		return PTR_ERR(res->axi_m_reset);
>  
> -	res->axi_s_reset = devm_reset_control_get(dev, "axi_s");
> +	res->axi_s_reset = devm_reset_control_get_exclusive(dev, "axi_s");
>  	if (IS_ERR(res->axi_s_reset))
>  		return PTR_ERR(res->axi_s_reset);
>  
> -	res->pipe_reset = devm_reset_control_get(dev, "pipe");
> +	res->pipe_reset = devm_reset_control_get_exclusive(dev, "pipe");
>  	if (IS_ERR(res->pipe_reset))
>  		return PTR_ERR(res->pipe_reset);
>  
> -	res->axi_m_vmid_reset = devm_reset_control_get(dev, "axi_m_vmid");
> +	res->axi_m_vmid_reset = devm_reset_control_get_exclusive(dev,
> +								 "axi_m_vmid");
>  	if (IS_ERR(res->axi_m_vmid_reset))
>  		return PTR_ERR(res->axi_m_vmid_reset);
>  
> -	res->axi_s_xpu_reset = devm_reset_control_get(dev, "axi_s_xpu");
> +	res->axi_s_xpu_reset = devm_reset_control_get_exclusive(dev,
> +								"axi_s_xpu");
>  	if (IS_ERR(res->axi_s_xpu_reset))
>  		return PTR_ERR(res->axi_s_xpu_reset);
>  
> -	res->parf_reset = devm_reset_control_get(dev, "parf");
> +	res->parf_reset = devm_reset_control_get_exclusive(dev, "parf");
>  	if (IS_ERR(res->parf_reset))
>  		return PTR_ERR(res->parf_reset);
>  
> -	res->phy_reset = devm_reset_control_get(dev, "phy");
> +	res->phy_reset = devm_reset_control_get_exclusive(dev, "phy");
>  	if (IS_ERR(res->phy_reset))
>  		return PTR_ERR(res->phy_reset);
>  
> -	res->axi_m_sticky_reset = devm_reset_control_get(dev, "axi_m_sticky");
> +	res->axi_m_sticky_reset = devm_reset_control_get_exclusive(dev,
> +								   "axi_m_sticky");
>  	if (IS_ERR(res->axi_m_sticky_reset))
>  		return PTR_ERR(res->axi_m_sticky_reset);
>  
> -	res->pipe_sticky_reset = devm_reset_control_get(dev, "pipe_sticky");
> +	res->pipe_sticky_reset = devm_reset_control_get_exclusive(dev,
> +								  "pipe_sticky");
>  	if (IS_ERR(res->pipe_sticky_reset))
>  		return PTR_ERR(res->pipe_sticky_reset);
>  
> -	res->pwr_reset = devm_reset_control_get(dev, "pwr");
> +	res->pwr_reset = devm_reset_control_get_exclusive(dev, "pwr");
>  	if (IS_ERR(res->pwr_reset))
>  		return PTR_ERR(res->pwr_reset);
>  
> -	res->ahb_reset = devm_reset_control_get(dev, "ahb");
> +	res->ahb_reset = devm_reset_control_get_exclusive(dev, "ahb");
>  	if (IS_ERR(res->ahb_reset))
>  		return PTR_ERR(res->ahb_reset);
>  
> -	res->phy_ahb_reset = devm_reset_control_get(dev, "phy_ahb");
> +	res->phy_ahb_reset = devm_reset_control_get_exclusive(dev, "phy_ahb");
>  	if (IS_ERR(res->phy_ahb_reset))
>  		return PTR_ERR(res->phy_ahb_reset);
>  
> -- 
> 2.11.0
> 

Re: [PATCH 000/102] Convert drivers to explicit reset API

[Thomas Petazzoni]

Hello,

On Wed, 19 Jul 2017 17:25:04 +0200, Philipp Zabel wrote:
> The reset control API has two modes: exclusive access, where the driver
> expects to have full and immediate control over the state of the reset
> line, and shared (clock-like) access, where drivers only request reset
> deassertion while active, but don't care about the state of the reset line
> while inactive.
> 
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior.
> 
> This series converts all drivers that currently implicitly request
> exclusive reset controls to the corresponding explicit API call. It is,
> for the most part, generated from the following semantic patch:
> 
> @@
> expression rstc, dev, id;
> @@
> -rstc = reset_control_get(dev, id);
> +rstc = reset_control_get_exclusive(dev, id);

I don't know if it has been discussed in the past, so forgive me if it
has been. Have you considered adding a "int flags" argument to the
existing reset_control_get_*() functions, rather than introducing
separate exclusive variants ?

Indeed, with a "int flags" argument you could in the future add more
variants/behaviors without actually multiplying the number of
functions. Something like the "flags" argument for request_irq() for
example.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 000/102] Convert drivers to explicit reset API

[Philipp Zabel]

Hi Thomas,

On Wed, 2017-07-19 at 21:15 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Wed, 19 Jul 2017 17:25:04 +0200, Philipp Zabel wrote:
> > The reset control API has two modes: exclusive access, where the driver
> > expects to have full and immediate control over the state of the reset
> > line, and shared (clock-like) access, where drivers only request reset
> > deassertion while active, but don't care about the state of the reset line
> > while inactive.
> > 
> > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> > reset lines") started to transition the reset control request API calls
> > to explicitly state whether the driver needs exclusive or shared reset
> > control behavior.
> > 
> > This series converts all drivers that currently implicitly request
> > exclusive reset controls to the corresponding explicit API call. It is,
> > for the most part, generated from the following semantic patch:
> > 
> > @@
> > expression rstc, dev, id;
> > @@
> > -rstc = reset_control_get(dev, id);
> > +rstc = reset_control_get_exclusive(dev, id);
> 
> I don't know if it has been discussed in the past, so forgive me if it
> has been. Have you considered adding a "int flags" argument to the
> existing reset_control_get_*() functions, rather than introducing
> separate exclusive variants ?
> 
> Indeed, with a "int flags" argument you could in the future add more
> variants/behaviors without actually multiplying the number of
> functions. Something like the "flags" argument for request_irq() for
> example.

I can't find the discussion right now, but I remember we had talked
about this in the past.
Behind the scenes, all the inline API functions already call common
entry points with flags (well, currently separate bool parameters for
shared and optional).
One reason against exposing those as an int flags in the user facing API
is the possibility to accidentally provide a wrong value.

regards
Philipp

Re: [PATCH 000/102] Convert drivers to explicit reset API

[Thomas Petazzoni]

Hello,

On Thu, 20 Jul 2017 11:36:55 +0200, Philipp Zabel wrote:

> > I don't know if it has been discussed in the past, so forgive me if it
> > has been. Have you considered adding a "int flags" argument to the
> > existing reset_control_get_*() functions, rather than introducing
> > separate exclusive variants ?
> > 
> > Indeed, with a "int flags" argument you could in the future add more
> > variants/behaviors without actually multiplying the number of
> > functions. Something like the "flags" argument for request_irq() for
> > example.  
> 
> I can't find the discussion right now, but I remember we had talked
> about this in the past.
> Behind the scenes, all the inline API functions already call common
> entry points with flags (well, currently separate bool parameters for
> shared and optional).
> One reason against exposing those as an int flags in the user facing API
> is the possibility to accidentally provide a wrong value.

This is a quite strange argument. You could also accidentally use the
wrong variant of the function, just like you could use the wrong flag.

Once again, the next time you have another parameter for those reset
functions, beyond the exclusive/shared variant, you will multiply again
by two the number of functions ? You already have the  exclusive/shared
and optional/mandatory variants, so 4 variants. When you'll add a new
parameter, you'll have 8 variants. Doesn't seem really good.

What about reset_control_get(struct device *, const char *, int flags)
to replace all those variants ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 000/102] Convert drivers to explicit reset API

[Philipp Zabel]

Hi Thomas,

On Thu, 2017-07-20 at 12:36 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 20 Jul 2017 11:36:55 +0200, Philipp Zabel wrote:
> 
> > > I don't know if it has been discussed in the past, so forgive me if it
> > > has been. Have you considered adding a "int flags" argument to the
> > > existing reset_control_get_*() functions, rather than introducing
> > > separate exclusive variants ?
> > > 
> > > Indeed, with a "int flags" argument you could in the future add more
> > > variants/behaviors without actually multiplying the number of
> > > functions. Something like the "flags" argument for request_irq() for
> > > example.  
> > 
> > I can't find the discussion right now, but I remember we had talked
> > about this in the past.
> > Behind the scenes, all the inline API functions already call common
> > entry points with flags (well, currently separate bool parameters for
> > shared and optional).
> > One reason against exposing those as an int flags in the user facing API
> > is the possibility to accidentally provide a wrong value.
> 
> This is a quite strange argument. You could also accidentally use the
> wrong variant of the function, just like you could use the wrong flag.

You can't accidentally use no flag at all or a completely bogus value
with the "plethora of inline functions" variant.

> Once again, the next time you have another parameter for those reset
> functions, beyond the exclusive/shared variant, you will multiply again
> by two the number of functions ? You already have the  exclusive/shared
> and optional/mandatory variants, so 4 variants. When you'll add a new
> parameter, you'll have 8 variants. Doesn't seem really good.

I'd rather avoid adding more variants, if possible. The complexity
increases regardless of whether the API is expressed as a bunch of
functions or as a single function with a bunch of flags.

> What about reset_control_get(struct device *, const char *, int flags)
> to replace all those variants ?

While I like how this looks, unfortunately (devm_)reset_control_get
already exists without the flags, so we can't change to that with a
gentle transition.

regards
Philipp

Re: [PATCH 000/102] Convert drivers to explicit reset API

[Dmitry Torokhov]

On Thu, Jul 20, 2017 at 5:55 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Hi Thomas,
>
> On Thu, 2017-07-20 at 12:36 +0200, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Thu, 20 Jul 2017 11:36:55 +0200, Philipp Zabel wrote:
>>
>> > > I don't know if it has been discussed in the past, so forgive me if it
>> > > has been. Have you considered adding a "int flags" argument to the
>> > > existing reset_control_get_*() functions, rather than introducing
>> > > separate exclusive variants ?
>> > >
>> > > Indeed, with a "int flags" argument you could in the future add more
>> > > variants/behaviors without actually multiplying the number of
>> > > functions. Something like the "flags" argument for request_irq() for
>> > > example.
>> >
>> > I can't find the discussion right now, but I remember we had talked
>> > about this in the past.
>> > Behind the scenes, all the inline API functions already call common
>> > entry points with flags (well, currently separate bool parameters for
>> > shared and optional).
>> > One reason against exposing those as an int flags in the user facing API
>> > is the possibility to accidentally provide a wrong value.
>>
>> This is a quite strange argument. You could also accidentally use the
>> wrong variant of the function, just like you could use the wrong flag.
>
> You can't accidentally use no flag at all or a completely bogus value
> with the "plethora of inline functions" variant.
>
>> Once again, the next time you have another parameter for those reset
>> functions, beyond the exclusive/shared variant, you will multiply again
>> by two the number of functions ? You already have the  exclusive/shared
>> and optional/mandatory variants, so 4 variants. When you'll add a new
>> parameter, you'll have 8 variants. Doesn't seem really good.
>
> I'd rather avoid adding more variants, if possible. The complexity
> increases regardless of whether the API is expressed as a bunch of
> functions or as a single function with a bunch of flags.
>
>> What about reset_control_get(struct device *, const char *, int flags)
>> to replace all those variants ?
>
> While I like how this looks, unfortunately (devm_)reset_control_get
> already exists without the flags, so we can't change to that with a
> gentle transition.

This was done for gpiod_get() and its flags argument with horrifying
#define-ry, which thankfully was completely hidden from users.

-- 
Dmitry

Re: [PATCH 000/102] Convert drivers to explicit reset API

[Linus Walleij]

On Thu, Jul 20, 2017 at 10:46 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Thu, Jul 20, 2017 at 5:55 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:

>>> What about reset_control_get(struct device *, const char *, int flags)
>>> to replace all those variants ?
>>
>> While I like how this looks, unfortunately (devm_)reset_control_get
>> already exists without the flags, so we can't change to that with a
>> gentle transition.
>
> This was done for gpiod_get() and its flags argument with horrifying
> #define-ry, which thankfully was completely hidden from users.

For your reference:

commit bae48da237fcedd7ad09569025483b988635efb7
"gpiolib: add gpiod_get() and gpiod_put() functions"

commit 39b2bbe3d715cf5013b5c48695ccdd25bd3bf120
"gpio: add flags argument to gpiod_get*() functions"

commit 0dbc8b7afef6e4fddcfebcbacbeb269a0a3b06d5
"gpio: move varargs hack outside #ifdef GPIOLIB"

commit b17d1bf16cc72a374a48d748940f700009d40ff4
"gpio: make flags mandatory for gpiod_get functions"

Retrospectively ... was that really a good idea... it was a LOT
of trouble to add a flag, maybe it had been better to try and
just slam all users in a single go.

But it worked.

Yours,
Linus Walleij

Re: [PATCH 000/102] Convert drivers to explicit reset API

[Philipp Zabel]

On Sun, 2017-07-23 at 20:41 +0200, Linus Walleij wrote:
> On Thu, Jul 20, 2017 at 10:46 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Thu, Jul 20, 2017 at 5:55 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> 
> >>> What about reset_control_get(struct device *, const char *, int flags)
> >>> to replace all those variants ?
> >>
> >> While I like how this looks, unfortunately (devm_)reset_control_get
> >> already exists without the flags, so we can't change to that with a
> >> gentle transition.
> >
> > This was done for gpiod_get() and its flags argument with horrifying
> > #define-ry, which thankfully was completely hidden from users.
> 
> For your reference:
> 
> commit bae48da237fcedd7ad09569025483b988635efb7
> "gpiolib: add gpiod_get() and gpiod_put() functions"
> 
> commit 39b2bbe3d715cf5013b5c48695ccdd25bd3bf120
> "gpio: add flags argument to gpiod_get*() functions"
> 
> commit 0dbc8b7afef6e4fddcfebcbacbeb269a0a3b06d5
> "gpio: move varargs hack outside #ifdef GPIOLIB"
> 
> commit b17d1bf16cc72a374a48d748940f700009d40ff4
> "gpio: make flags mandatory for gpiod_get functions"
> 
> Retrospectively ... was that really a good idea... it was a LOT
> of trouble to add a flag, maybe it had been better to try and
> just slam all users in a single go.
> 
> But it worked.

Thanks for the hint and the references. It seems this turned out okay,
but I wouldn't dare to introduce such macro horror^Wmagic.
I'd rather have all users converted to the _exclusive/_shared function
calls and maybe then replace the internal __reset_control_get with
Thomas' suggestion.

regards
Philipp

Re: [PATCH 000/102] Convert drivers to explicit reset API

[Wolfram Sang]

[-- Attachment #1.1: Type: text/plain, Size: 378 bytes --]


> Thanks for the hint and the references. It seems this turned out okay,
> but I wouldn't dare to introduce such macro horror^Wmagic.
> I'd rather have all users converted to the _exclusive/_shared function
> calls and maybe then replace the internal __reset_control_get with
> Thomas' suggestion.

I didn't follow the discussion closely. Shall I still apply the i2c
patches?


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 200 bytes --]

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 000/102] Convert drivers to explicit reset API

[Philipp Zabel]

On Sat, 2017-08-12 at 13:43 +0200, Wolfram Sang wrote:
> > Thanks for the hint and the references. It seems this turned out
> > okay,
> > but I wouldn't dare to introduce such macro horror^Wmagic.
> > I'd rather have all users converted to the _exclusive/_shared
> > function
> > calls and maybe then replace the internal __reset_control_get with
> > Thomas' suggestion.
> 
> I didn't follow the discussion closely. Shall I still apply the i2c
> patches?

Yes, please.

regards
Philipp

Re: [PATCH 000/102] Convert drivers to explicit reset API

[Maxime Ripard]

[-- Attachment #1.1: Type: text/plain, Size: 8914 bytes --]

On Wed, Jul 19, 2017 at 05:25:04PM +0200, Philipp Zabel wrote:
> The reset control API has two modes: exclusive access, where the driver
> expects to have full and immediate control over the state of the reset
> line, and shared (clock-like) access, where drivers only request reset
> deassertion while active, but don't care about the state of the reset line
> while inactive.
> 
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior.
> 
> This series converts all drivers that currently implicitly request
> exclusive reset controls to the corresponding explicit API call. It is,
> for the most part, generated from the following semantic patch:
> 
> @@
> expression rstc, dev, id;
> @@
> -rstc = reset_control_get(dev, id);
> +rstc = reset_control_get_exclusive(dev, id);
> @@
> expression rstc, dev, id;
> @@
> -rstc = reset_control_get_optional(dev, id);
> +rstc = reset_control_get_optional_exclusive(dev, id);
> @@
> expression rstc, node, id;
> @@
> -rstc = of_reset_control_get(node, id);
> +rstc = of_reset_control_get_exclusive(node, id);
> @@
> expression rstc, node, index;
> @@
> -rstc = of_reset_control_get_by_index(node, index);
> +rstc = of_reset_control_get_exclusive_by_index(node, index);
> @@
> expression rstc, dev, id;
> @@
> -rstc = devm_reset_control_get(dev, id);
> +rstc = devm_reset_control_get_exclusive(dev, id);
> @@
> expression rstc, dev, id;
> @@
> -rstc = devm_reset_control_get_optional(dev, id);
> +rstc = devm_reset_control_get_optional_exclusive(dev, id);
> @@
> expression rstc, dev, index;
> @@
> -rstc = devm_reset_control_get_by_index(dev, index);
> +rstc = devm_reset_control_get_exclusive_by_index(dev, index);
> 
> After all driver patches are applied, the temporary transition helpers
> can be removed.
> 
> regards
> Philipp
> 
> Philipp Zabel (102):
>   ARM: rockchip: explicitly request exclusive reset control
>   ARM: socfpga: explicitly request exclusive reset control
>   MIPS: pci-mt7620: explicitly request exclusive reset control
>   ahci: st: explicitly request exclusive reset control
>   ata: sata_gemini: explicitly request exclusive reset control
>   ata: ahci_tegra: explicitly request exclusive reset control
>   bus: sunxi-rsb: explicitly request exclusive reset control
>   bus: tegra-gmi: explicitly request exclusive reset control
>   clk: sunxi: explicitly request exclusive reset control
>   clk: tegra: explicitly request exclusive reset control
>   clocksource/drivers/timer-stm32: explicitly request exclusive reset
>     control
>   clocksource/drivers/sun5i: explicitly request exclusive reset control
>   crypto: rockchip: explicitly request exclusive reset control
>   crypto: sun4i-ss - request exclusive reset control
>   PM / devfreq: tegra: explicitly request exclusive reset control
>   dmaengine: stm32-dma: explicitly request exclusive reset control
>   dmaengine: sun6i: explicitly request exclusive reset control
>   dmaengine: tegra-apb: explicitly request exclusive reset control
>   drm: kirin: explicitly request exclusive reset control
>   drm/nouveau/tegra: explicitly request exclusive reset control
>   drm/rockchip: explicitly request exclusive reset control
>   drm/sti: explicitly request exclusive reset control
>   drm/stm: explicitly request exclusive reset control
>   drm/sun4i: explicitly request exclusive reset control
>   drm/tegra: explicitly request exclusive reset control
>   gpu: host1x: explicitly request exclusive reset control
>   i2c: mv64xxx: explicitly request exclusive reset control
>   i2c: stm32f4: explicitly request exclusive reset control
>   i2c: sun6i-pw2i: explicitly request exclusive reset control
>   i2c: tegra: explicitly request exclusive reset control
>   iio: adc: rockchip_saradc: explicitly request exclusive reset control
>   iio: dac: stm32-dac-core: explicitly request exclusive reset control
>   Input: tegra-kbc - request exclusive reset control
>   coda: explicitly request exclusive reset control
>   st-rc: explicitly request exclusive reset control
>   stm32-dcmi: explicitly request exclusive reset control
>   rc: sunxi-cir: explicitly request exclusive reset control
>   mmc: dw_mmc: explicitly request exclusive reset control
>   mmc: sdhci-st: explicitly request exclusive reset control
>   mmc: sunxi: explicitly request exclusive reset control
>   mmc: tegra: explicitly request exclusive reset control
>   mtd: nand: sunxi: explicitly request exclusive reset control
>   mtd: spi-nor: stm32-quadspi: explicitly request exclusive reset
>     control
>   net: dsa: mt7530: explicitly request exclusive reset control
>   net: ethernet: hisi_femac: explicitly request exclusive reset control
>   net: ethernet: hix5hd2_gmac: explicitly request exclusive reset
>     control
>   net: stmmac: explicitly request exclusive reset control
>   net: stmmac: dwc-qos: explicitly request exclusive reset control
>   ath10k: explicitly request exclusive reset control
>   nvmem: lpc18xx-eeprom: explicitly request exclusive reset control
>   PCI: dwc: pcie-qcom: explicitly request exclusive reset control
>   PCI: imx6: explicitly request exclusive reset control
>   PCI: tegra: explicitly request exclusive reset control
>   PCI: rockchip: explicitly request exclusive reset control
>   phy: berlin-usb: explicitly request exclusive reset control
>   PCI: mediatek: explicitly request exclusive reset control
>   phy: qcom-usb-hs: explicitly request exclusive reset control
>   phy: rockchip-pcie: explicitly request exclusive reset control
>   phy: rockchip-typec: explicitly request exclusive reset control
>   phy: rockchip-usb: explicitly request exclusive reset control
>   phy: sun4i-usb: explicitly request exclusive reset control
>   phy: sun9i-usb: explicitly request exclusive reset control
>   phy: tegra: explicitly request exclusive reset control
>   phy: qcom-qmp: explicitly request exclusive reset control
>   phy: qcom-qusb2: explicitly request exclusive reset control
>   pinctrl: stm32: explicitly request exclusive reset control
>   pinctrl: sunxi: explicitly request exclusive reset control
>   pinctrl: tegra: explicitly request exclusive reset control
>   pwm: hibvt: explicitly request exclusive reset control
>   pwm: tegra: explicitly request exclusive reset control
>   remoteproc/keystone: explicitly request exclusive reset control
>   remoteproc: qcom: explicitly request exclusive reset control
>   remoteproc: st: explicitly request exclusive reset control
>   soc: mediatek: PMIC wrap: explicitly request exclusive reset control
>   soc/tegra: pmc: explicitly request exclusive reset control
>   spi: stm32: explicitly request exclusive reset control
>   spi: sun6i: explicitly request exclusive reset control
>   spi: tegra20-slink: explicitly request exclusive reset control
>   spi: tegra114: explicitly request exclusive reset control
>   spi: tegra20-sflash: explicitly request exclusive reset control
>   staging: nvec: explicitly request exclusive reset control
>   thermal: rockchip: explicitly request exclusive reset control
>   thermal: tegra: explicitly request exclusive reset control
>   serial: 8250_dw: explicitly request exclusive reset control
>   serial: tegra: explicitly request exclusive reset control
>   usb: chipidea: msm: explicitly request exclusive reset control
>   usb: dwc2: explicitly request exclusive reset control
>   usb: host: ehci-tegra: explicitly request exclusive reset control
>   usb: host: xhci-tegra: explicitly request exclusive reset control
>   usb: musb: sunxi: explicitly request exclusive reset control
>   usb: phy: msm: explicitly request exclusive reset control
>   usb: phy: qcom-8x16-usb: explicitly request exclusive reset control
>   watchdog: asm9260: explicitly request exclusive reset control
>   watchdog: mt7621: explicitly request exclusive reset control
>   watchdog: rt2880: explicitly request exclusive reset control
>   watchdog: zx2967: explicitly request exclusive reset control
>   ASoC: img: explicitly request exclusive reset control
>   ASoC: stm32: explicitly request exclusive reset control
>   ASoC: sun4i: explicitly request exclusive reset control
>   ASoC: tegra: explicitly request exclusive reset control
>   Documentation: devres: add explicit exclusive/shared reset control
>     request calls
>   reset: finish transition to explicit exclusive reset control requests


For all sunxi patches:
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 200 bytes --]

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 000/102] Convert drivers to explicit reset API

[Greg Kroah-Hartman]

On Wed, Jul 19, 2017 at 05:25:04PM +0200, Philipp Zabel wrote:
> The reset control API has two modes: exclusive access, where the driver
> expects to have full and immediate control over the state of the reset
> line, and shared (clock-like) access, where drivers only request reset
> deassertion while active, but don't care about the state of the reset line
> while inactive.
> 
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior.
> 
> This series converts all drivers that currently implicitly request
> exclusive reset controls to the corresponding explicit API call. It is,
> for the most part, generated from the following semantic patch:

Hey, I'm all for large api changes, but this really seems ackward, isn't
there a "better" way to do this?

Why not, as you say the "implicit" request is exclusive, just leave
everything alone and state that the "reset_control_get()" call is
exclusive and make the shared one the "odd" usage as that seems to not
be the normal case.

That should be a much smaller patch right?

That way you don't break everything here, and require 100+ patches to
just change the name of a function from one to another and do nothing
else.

thanks,

greg k-h

Re: [PATCH 000/102] Convert drivers to explicit reset API

[Philipp Zabel]

Hi Greg,

The patches in this series are completely independent of each other, and
I would like the subsystem maintainers to apply them at their own
leisure.
Well, except for the last one, which I will apply only after there are
no more users of the transition helpers.

On Thu, 2017-07-20 at 10:11 +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 05:25:04PM +0200, Philipp Zabel wrote:
> > The reset control API has two modes: exclusive access, where the driver
> > expects to have full and immediate control over the state of the reset
> > line, and shared (clock-like) access, where drivers only request reset
> > deassertion while active, but don't care about the state of the reset line
> > while inactive.
> > 
> > Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> > reset lines") started to transition the reset control request API calls
> > to explicitly state whether the driver needs exclusive or shared reset
> > control behavior.
> > 
> > This series converts all drivers that currently implicitly request
> > exclusive reset controls to the corresponding explicit API call. It is,
> > for the most part, generated from the following semantic patch:
> 
> Hey, I'm all for large api changes, but this really seems ackward, isn't
> there a "better" way to do this?

It is a bit awkward. I am sorry I haven't done this earlier. Quite a few
new drivers started using the old API after the explicit requests were
introduced last year.

> Why not, as you say the "implicit" request is exclusive, just leave
> everything alone and state that the "reset_control_get()" call is
> exclusive 

I think it is better to let the drivers explicitly state what they
expect from the API, and using reset_control_get_exclusive vs _shared
helps driver developers to make a conscious decision.

Further, the implicit API call predates shared reset support, so it is
not clear that all of the old users really need exclusive control.
A few drivers have been switched to the shared API already.

> and make the shared one the "odd" usage as that seems to not
> be the normal case.

I am not sure, there have been people arguing that the "clock-like" case
really is the common one. I suppose some of those drivers touched by the
100 patches in this series could also be changed to shared. But I don't
dare to make this decision for each of them.

> That should be a much smaller patch right?
> 
> That way you don't break everything here, and require 100+ patches to
> just change the name of a function from one to another and do nothing
> else.

I don't break anything here, and I'm absolutely fine with squashing
patches together per subsystem where that is preferable.

regards
Philipp

(no subject)

[Heiko Stuebner]

Hi,

>   crypto: rockchip: explicitly request exclusive reset control
>   iio: adc: rockchip_saradc: explicitly request exclusive reset control
>   PCI: rockchip: explicitly request exclusive reset control
>   phy: rockchip-pcie: explicitly request exclusive reset control
>   phy: rockchip-typec: explicitly request exclusive reset control
>   phy: rockchip-usb: explicitly request exclusive reset control
>   thermal: rockchip: explicitly request exclusive reset control

for the driver-related Rockchip changes

Acked-by: Heiko Stuebner <heiko@sntech.de>

(No Subject)

[Caleb Connolly]

Subject: v2: arm64: dts: sm8150: start populating qups

The QUPs are rather sparse, lets add the zero-th and second qup nodes,
the iommus properties for all of them and the i2c nodes.

With this it's now possible to bringup the touchscreen on my
device, and without crashing!

Derived from OnePlus 7 Pro downstream kernel sources.

	Caleb
---
Of note, I'm only able to properly test i2c17, as that's what my
touchscreen is attached to. Enabling i2c18 causes my device to lockup
during probe, I suspect those pins are used for some other purpose on my
device.

Changes since v1:
 * Pick up Reviewed-By's from Vinod and Bhupesh
 * Squash second patch into first
 * Add iommus property to dt-binding docs for geni
 * Fix i2c19 being mistakenly enabled by default

Caleb Connolly (3):
      arm64: dts: qcom: sm8150: add other QUP nodes and iommus
      arm64: dts: qcom: sm8150: add i2c nodes
      dt-bindings: qcom: geni-se: document iommus

 arch/arm64/boot/dts/qcom/sm8150.dtsi | 549 +++++++++++++++++++++++++++++++++++
 1 file changed, 549 insertions(+)

Re: (No Subject)

[Dmitry Baryshkov]

On Sun, 21 Mar 2021 at 20:47, Caleb Connolly <caleb@connolly.tech> wrote:
>
> Subject: v2: arm64: dts: sm8150: start populating qups
>
> The QUPs are rather sparse, lets add the zero-th and second qup nodes,
> the iommus properties for all of them and the i2c nodes.
>
> With this it's now possible to bringup the touchscreen on my
> device, and without crashing!
>
> Derived from OnePlus 7 Pro downstream kernel sources.
>
>         Caleb

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

> ---
> Of note, I'm only able to properly test i2c17, as that's what my
> touchscreen is attached to. Enabling i2c18 causes my device to lockup
> during probe, I suspect those pins are used for some other purpose on my
> device.
>
> Changes since v1:
>  * Pick up Reviewed-By's from Vinod and Bhupesh
>  * Squash second patch into first
>  * Add iommus property to dt-binding docs for geni
>  * Fix i2c19 being mistakenly enabled by default
>
> Caleb Connolly (3):
>       arm64: dts: qcom: sm8150: add other QUP nodes and iommus
>       arm64: dts: qcom: sm8150: add i2c nodes
>       dt-bindings: qcom: geni-se: document iommus
>
>  arch/arm64/boot/dts/qcom/sm8150.dtsi | 549 +++++++++++++++++++++++++++++++++++
>  1 file changed, 549 insertions(+)
>
>


-- 
With best wishes
Dmitry

(No Subject)

[Yassine Oudjana]

Date: Tue, 22 Jun 2021 20:08:25 +0400
Subject: [PATCH] media: dt-bindings: media: venus: Add firmware-name

Support for parsing the firmware-name property was added a while ago [1],
but the dt-bindings were never updated with the new property. This patch
adds it to all venus dt-bindings.

Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>

[1]: https://lore.kernel.org/linux-arm-msm/20210126084252.238078-1-stanimir.varbanov@linaro.org/
---
 .../devicetree/bindings/media/qcom,msm8916-venus.yaml        | 5 +++++
 .../devicetree/bindings/media/qcom,msm8996-venus.yaml        | 5 +++++
 .../devicetree/bindings/media/qcom,sc7180-venus.yaml         | 5 +++++
 .../devicetree/bindings/media/qcom,sdm845-venus-v2.yaml      | 5 +++++
 .../devicetree/bindings/media/qcom,sdm845-venus.yaml         | 5 +++++
 5 files changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
index 59ab16ad12f1..cb1b866d9c37 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
@@ -80,6 +80,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
index 199f45217b4a..b8809325138f 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
@@ -107,6 +107,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
index 04013e5dd044..ffd3e2850366 100644
--- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
@@ -99,6 +99,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
index 04b9af4db191..cd7a5e1374ce 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
@@ -94,6 +94,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
index 680f37726fdf..ae256238a637 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
@@ -108,6 +108,11 @@ properties:
     required:
       - iommus
 
+  firmware-name:
+    maxItems: 1
+    description: |
+      Relative firmware image path for venus.
+
 required:
   - compatible
   - reg
-- 
2.32.0

Re: (No Subject)

[Rob Herring]

On Tue, Jun 22, 2021 at 04:20:24PM +0000, Yassine Oudjana wrote:
> Date: Tue, 22 Jun 2021 20:08:25 +0400
> Subject: [PATCH] media: dt-bindings: media: venus: Add firmware-name
> 
> Support for parsing the firmware-name property was added a while ago [1],
> but the dt-bindings were never updated with the new property. This patch
> adds it to all venus dt-bindings.
> 
> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
> 
> [1]: https://lore.kernel.org/linux-arm-msm/20210126084252.238078-1-stanimir.varbanov@linaro.org/
> ---
>  .../devicetree/bindings/media/qcom,msm8916-venus.yaml        | 5 +++++
>  .../devicetree/bindings/media/qcom,msm8996-venus.yaml        | 5 +++++
>  .../devicetree/bindings/media/qcom,sc7180-venus.yaml         | 5 +++++
>  .../devicetree/bindings/media/qcom,sdm845-venus-v2.yaml      | 5 +++++
>  .../devicetree/bindings/media/qcom,sdm845-venus.yaml         | 5 +++++
>  5 files changed, 25 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
> index 59ab16ad12f1..cb1b866d9c37 100644
> --- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml
> @@ -80,6 +80,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1

Not an array.

Is there a specific pattern and/or default name you can specify?

> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
> index 199f45217b4a..b8809325138f 100644
> --- a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml
> @@ -107,6 +107,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> index 04013e5dd044..ffd3e2850366 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> @@ -99,6 +99,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> index 04b9af4db191..cd7a5e1374ce 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> @@ -94,6 +94,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
> index 680f37726fdf..ae256238a637 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml
> @@ -108,6 +108,11 @@ properties:
>      required:
>        - iommus
>  
> +  firmware-name:
> +    maxItems: 1
> +    description: |
> +      Relative firmware image path for venus.
> +
>  required:
>    - compatible
>    - reg
> -- 
> 2.32.0
> 
> 
> 

[PATCH] drivers/gpu: Switching Adreno x1-85 device check to family check.

[John Schulz]

Switches the is_x185 check to is_x1xx_family to accommodate more devices.
Note that I got the X1-45 GPU ID from Windows which may not be correct.

Signed-off-by: John Schulz <john.schulz1@protonmail.com>
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   |  3 ++-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h | 12 +++++++++---
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 06cab2c6fd66..f04aeacae3c2 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -2,6 +2,7 @@
 /* Copyright (c) 2017-2019 The Linux Foundation. All rights reserved. */
 
 
+#include "adreno_gpu.h"
 #include "msm_gem.h"
 #include "msm_mmu.h"
 #include "msm_gpu_trace.h"
@@ -1026,7 +1027,7 @@ static int hw_init(struct msm_gpu *gpu)
 	gpu_write(gpu, REG_A6XX_UCHE_CLIENT_PF, BIT(7) | 0x1);
 
 	/* Set weights for bicubic filtering */
-	if (adreno_is_a650_family(adreno_gpu) || adreno_is_x185(adreno_gpu)) {
+	if (adreno_is_a650_family(adreno_gpu) || adreno_is_x1xx_family(adreno_gpu)) {
 		gpu_write(gpu, REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_0, 0);
 		gpu_write(gpu, REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_1,
 			0x3fe05ff4);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 58d7e7915c57..ec36fc915433 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -526,9 +526,15 @@ static inline int adreno_is_a750(struct adreno_gpu *gpu)
 	return gpu->info->chip_ids[0] == 0x43051401;
 }
 
-static inline int adreno_is_x185(struct adreno_gpu *gpu)
-{
-	return gpu->info->chip_ids[0] == 0x43050c01;
+static inline int adreno_is_x1xx_family(struct adreno_gpu *gpu)
+{
+	switch (gpu->info->chip_ids[0]) {
+	case 0x1fc31043; // X1-45
+	case 0x43050c01; // X1-85
+		return 1;
+	default:
+		return 0;
+	}
 }
 
 static inline int adreno_is_a740_family(struct adreno_gpu *gpu)
-- 
2.46.1

Re: [PATCH] drivers/gpu: Switching Adreno x1-85 device check to family check.

[Dmitry Baryshkov]

On Sat, Sep 21, 2024 at 08:42:54PM GMT, John Schulz wrote:

Subject prefix is not correct, it should be drm/msm

> Switches the is_x185 check to is_x1xx_family to accommodate more devices.
> Note that I got the X1-45 GPU ID from Windows which may not be correct.

How did you test it? It's not that the driver is going to work on that
GPU without a catalog entry.

> 
> Signed-off-by: John Schulz <john.schulz1@protonmail.com>
> ---
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.c   |  3 ++-
>  drivers/gpu/drm/msm/adreno/adreno_gpu.h | 12 +++++++++---
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 06cab2c6fd66..f04aeacae3c2 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -2,6 +2,7 @@
>  /* Copyright (c) 2017-2019 The Linux Foundation. All rights reserved. */
>  
>  
> +#include "adreno_gpu.h"
>  #include "msm_gem.h"
>  #include "msm_mmu.h"
>  #include "msm_gpu_trace.h"
> @@ -1026,7 +1027,7 @@ static int hw_init(struct msm_gpu *gpu)
>  	gpu_write(gpu, REG_A6XX_UCHE_CLIENT_PF, BIT(7) | 0x1);
>  
>  	/* Set weights for bicubic filtering */
> -	if (adreno_is_a650_family(adreno_gpu) || adreno_is_x185(adreno_gpu)) {
> +	if (adreno_is_a650_family(adreno_gpu) || adreno_is_x1xx_family(adreno_gpu)) {
>  		gpu_write(gpu, REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_0, 0);
>  		gpu_write(gpu, REG_A6XX_TPL1_BICUBIC_WEIGHTS_TABLE_1,
>  			0x3fe05ff4);
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index 58d7e7915c57..ec36fc915433 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -526,9 +526,15 @@ static inline int adreno_is_a750(struct adreno_gpu *gpu)
>  	return gpu->info->chip_ids[0] == 0x43051401;
>  }
>  
> -static inline int adreno_is_x185(struct adreno_gpu *gpu)
> -{
> -	return gpu->info->chip_ids[0] == 0x43050c01;
> +static inline int adreno_is_x1xx_family(struct adreno_gpu *gpu)
> +{
> +	switch (gpu->info->chip_ids[0]) {
> +	case 0x1fc31043; // X1-45

Just by comparing it with other IDs it looks like you got it backwards.

> +	case 0x43050c01; // X1-85
> +		return 1;
> +	default:
> +		return 0;
> +	}
>  }
>  
>  static inline int adreno_is_a740_family(struct adreno_gpu *gpu)
> -- 
> 2.46.1
> 
> 

-- 
With best wishes
Dmitry

(No Subject)

[John Schulz]

Hi Dmitry, 

I do not have a way of testing this patch. I do see your point in that it may be redundant/unnecessary
since basic/generic drivers should at the very least output a shell interface. 

Upon doing more research, I came across the fact that some X1 GPUs have OEM signing that prevent the 
driver from working. I suspect that is what I am running into when I try testing various distros. All
of them exhibit the same behavior of the display halting during the bootloader handoff and the HDMI
port does not output anything. Even the Debian 12 image from Linaro exhibits the same issue. 

I find this a bit odd given that there is a dts entry for the Asus Vivobook S 15 X1E varient. I 
don't see any comments on whether the dts for that laptop was tested. The Vivobook I have is the
X1P varient which, to my knowledge, is identical to the X1E one but a different SoC. 

Perhaps it would be of better use of my (and others) time figuring out if the GPU drivers not
working is due to OEM locking and if so, trying to unlock it. What do y'all think? 

P.S. Apologies for the incorrect prefix, should have done more research instead of trying to 
make an educated guess. 

Thanks,
John

Re: (No Subject)

[Rob Clark]

On Tue, Sep 24, 2024 at 8:55 AM John Schulz <john.schulz1@protonmail.com> wrote:
>
> Hi Dmitry,
>
> I do not have a way of testing this patch. I do see your point in that it may be redundant/unnecessary
> since basic/generic drivers should at the very least output a shell interface.
>
> Upon doing more research, I came across the fact that some X1 GPUs have OEM signing that prevent the
> driver from working. I suspect that is what I am running into when I try testing various distros. All
> of them exhibit the same behavior of the display halting during the bootloader handoff and the HDMI
> port does not output anything. Even the Debian 12 image from Linaro exhibits the same issue.
>
> I find this a bit odd given that there is a dts entry for the Asus Vivobook S 15 X1E varient. I
> don't see any comments on whether the dts for that laptop was tested. The Vivobook I have is the
> X1P varient which, to my knowledge, is identical to the X1E one but a different SoC.

I think we'd need an x1p variant of x1e80100.dtsi which has the
description of the SoC itself.. which I guess is similar, but not the
same as, x1e.  Maybe someone from qcom or linaro is already working on
this?

> Perhaps it would be of better use of my (and others) time figuring out if the GPU drivers not
> working is due to OEM locking and if so, trying to unlock it. What do y'all think?

It is probably not OEM locking that is the issue, but OEM signing of
zap shader.  If you look at the x1e laptops, as an example, the GPU
node has the device specific firmware-path for the zap shader, ie. for
the yoga 7x, it is:

&gpu {
        status = "okay";

        zap-shader {
                firmware-name = "qcom/x1e80100/LENOVO/83ED/qcdxkmsuc8380.mbn";
        };
};

That qcdxkmsuc8380.mbn file would need to be copied from the windows
partition currently.

BR,
-R

> P.S. Apologies for the incorrect prefix, should have done more research instead of trying to
> make an educated guess.
>
> Thanks,
> John
>
>
>

Re: (No Subject)

[Dmitry Baryshkov]

On Tue, Sep 24, 2024 at 03:54:59PM GMT, John Schulz wrote:
> Hi Dmitry, 
> 
> I do not have a way of testing this patch. I do see your point in that it may be redundant/unnecessary
> since basic/generic drivers should at the very least output a shell interface. 
> 
> Upon doing more research, I came across the fact that some X1 GPUs have OEM signing that prevent the 
> driver from working. I suspect that is what I am running into when I try testing various distros. All
> of them exhibit the same behavior of the display halting during the bootloader handoff and the HDMI
> port does not output anything. Even the Debian 12 image from Linaro exhibits the same issue. 

Ok. So you have a device with X1P, which you don't seem to be able to
get to work? Could you please try doing the following:

- you might need to modify the GPU DT node to use a different ID there.
  If your guess is right, you might need to specify qcom,adreno-4310c31f
  (this is from your patch)

- you need to define a corresponding entry in a7xx_gpus[]. Try using
  X1-85 as an inspiration.

- only with that in place the x1xx family makes sense.


Also it would be nice if you describe your issue. What exactly do you
observe and what doesn't seem to work?

> 
> I find this a bit odd given that there is a dts entry for the Asus Vivobook S 15 X1E varient. I 
> don't see any comments on whether the dts for that laptop was tested. The Vivobook I have is the
> X1P varient which, to my knowledge, is identical to the X1E one but a different SoC. 
> 
> Perhaps it would be of better use of my (and others) time figuring out if the GPU drivers not
> working is due to OEM locking and if so, trying to unlock it. What do y'all think? 
> 
> P.S. Apologies for the incorrect prefix, should have done more research instead of trying to 
> make an educated guess. 
> 
> Thanks,
> John
> 
> 

-- 
With best wishes
Dmitry