Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Nick Desaulniers 
On Sun, Nov 22, 2020 at 8:17 AM Kees Cook  wrote:
>
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > If none of the 140 patches here fix a real bug, and there is no change
> > to machine code then it sounds to me like a W=2 kind of a warning.
>
> FWIW, this series has found at least one bug so far:
> https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=kr...@mail.gmail.com/

So looks like the bulk of these are:
switch (x) {
  case 0:
++x;
  default:
break;
}

I have a patch that fixes those up for clang:
https://reviews.llvm.org/D91895

There's 3 other cases that don't quite match between GCC and Clang I
observe in the kernel:
switch (x) {
  case 0:
++x;
  default:
goto y;
}
y:;

switch (x) {
  case 0:
++x;
  default:
return;
}

switch (x) {
  case 0:
++x;
  default:
;
}

Based on your link, and Nathan's comment on my patch, maybe Clang
should continue to warn for the above (at least the `default: return;`
case) and GCC should change?  While the last case looks harmless,
there were only 1 or 2 across the tree in my limited configuration
testing; I really think we should just add `break`s for those.
-- 
Thanks,
~Nick Desaulniers
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[staging:staging-testing] BUILD SUCCESS 8a3f7b9665c8194f32afec9a7bb60e2376f896c6

2020-11-23 Thread kernel test robot 
   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
i386 randconfig-a004-20201123
i386 randconfig-a003-20201123
i386 randconfig-a002-20201123
i386 randconfig-a005-20201123
i386 randconfig-a001-20201123
i386 randconfig-a006-20201123
x86_64   randconfig-a015-20201123
x86_64   randconfig-a011-20201123
x86_64   randconfig-a014-20201123
x86_64   randconfig-a016-20201123
x86_64   randconfig-a012-20201123
x86_64   randconfig-a013-20201123
i386 randconfig-a012-20201123
i386 randconfig-a013-20201123
i386 randconfig-a011-20201123
i386 randconfig-a016-20201123
i386 randconfig-a014-20201123
i386 randconfig-a015-20201123
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a006-20201123
x86_64   randconfig-a003-20201123
x86_64   randconfig-a004-20201123
x86_64   randconfig-a005-20201123
x86_64   randconfig-a002-20201123
x86_64   randconfig-a001-20201123

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Jakub Kicinski 
On Mon, 23 Nov 2020 17:32:51 -0800 Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook  wrote:
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:  
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it sounds to me like a W=2 kind of a warning.  
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6qKAO8gxSp=kr...@mail.gmail.com/
> >   
> 
> So looks like the bulk of these are:
> switch (x) {
>   case 0:
> ++x;
>   default:
> break;
> }
> 
> I have a patch that fixes those up for clang:
> https://reviews.llvm.org/D91895


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread James Bottomley 
On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
>  wrote:
> > Well, I used git.  It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple of outliers back to February.
> 
> I can see ~10k insertions over ~1k commits and 15 years that mention
> a fallthrough in the entire repo. That is including some commits
> (like the biggest one, 960 insertions) that have nothing to do with C
> fallthrough. A single kernel release has an order of magnitude more
> changes than this...
> 
> But if we do the math, for an author, at even 1 minute per line
> change and assuming nothing can be automated at all, it would take 1
> month of work. For maintainers, a couple of trivial lines is noise
> compared to many other patches.

So you think a one line patch should take one minute to produce ... I
really don't think that's grounded in reality.  I suppose a one line
patch only takes a minute to merge with b4 if no-one reviews or tests
it, but that's not really desirable.

> In fact, this discussion probably took more time than the time it
> would take to review the 200 lines. :-)

I'm framing the discussion in terms of the whole series of changes we
have done for fall through, both what's in the tree currently (889
patches) both in terms of the produce and the consumer.  That's what I
used for my figures for cost.

> > We're also complaining about the inability to recruit maintainers:
> > 
> > https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> > 
> > And burn out:
> > 
> > http://antirez.com/news/129
> 
> Accepting trivial and useful 1-line patches

Part of what I'm trying to measure is the "and useful" bit because
that's not a given.

> is not what makes a voluntary maintainer quit...

so the proverb "straw which broke the camel's back" uniquely doesn't
apply to maintainers

>  Thankless work with demanding deadlines is.

That's another potential reason, but it doesn't may other reasons less
valid.

> > The whole crux of your argument seems to be maintainers' time isn't
> > important so we should accept all trivial patches
> 
> I have not said that, at all. In fact, I am a voluntary one and I
> welcome patches like this. It takes very little effort on my side to
> review and it helps the kernel overall.

Well, you know, subsystems are very different in terms of the amount of
patches a maintainer has to process per release cycle of the kernel. 
If a maintainer is close to capacity, additional patches, however
trivial, become a problem.  If a maintainer has spare cycles, trivial
patches may look easy.

> Paid maintainers are the ones that can take care of big
> features/reviews.
> 
> > What I'm actually trying to articulate is a way of measuring value
> > of the patch vs cost ... it has nothing really to do with who foots
> > the actual bill.
> 
> I understand your point, but you were the one putting it in terms of
> a junior FTE.

No, I evaluated the producer side in terms of an FTE.  What we're
mostly arguing about here is the consumer side: the maintainers and
people who have to rework their patch sets. I estimated that at 100h.

>  In my view, 1 month-work (worst case) is very much worth
> removing a class of errors from a critical codebase.
> 
> > One thesis I'm actually starting to formulate is that this
> > continual devaluing of maintainers is why we have so much
> > difficulty keeping and recruiting them.
> 
> That may very well be true, but I don't feel anybody has devalued
> maintainers in this discussion.

You seem to be saying that because you find it easy to merge trivial
patches, everyone should.  I'm reminded of a friend long ago who
thought being a Tees River Pilot was a sinecure because he could
navigate the Tees blindfold.  What he forgot, of course, is that just
because it's easy with a trawler doesn't mean it's easy with an oil
tanker.  In fact it takes longer to qualify as a Tees River Pilot than
it does to get a PhD.

James


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Jason Gunthorpe 
On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[driver-core:readfile] BUILD SUCCESS 652db3de96a630e8051ffa921286000bb9ee2727

2020-11-23 Thread kernel test robot 
   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
i386 randconfig-a004-20201123
i386 randconfig-a003-20201123
i386 randconfig-a002-20201123
i386 randconfig-a005-20201123
i386 randconfig-a001-20201123
i386 randconfig-a006-20201123
x86_64   randconfig-a015-20201123
x86_64   randconfig-a011-20201123
x86_64   randconfig-a014-20201123
x86_64   randconfig-a016-20201123
x86_64   randconfig-a012-20201123
x86_64   randconfig-a013-20201123
i386 randconfig-a012-20201123
i386 randconfig-a013-20201123
i386 randconfig-a011-20201123
i386 randconfig-a016-20201123
i386 randconfig-a014-20201123
i386 randconfig-a015-20201123
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
x86_64   rhel
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a006-20201123
x86_64   randconfig-a003-20201123
x86_64   randconfig-a004-20201123
x86_64   randconfig-a005-20201123
x86_64   randconfig-a002-20201123
x86_64   randconfig-a001-20201123

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[staging:staging-next] BUILD SUCCESS 03c1136af504bbc2cabda76af6b27fd5f7cf8a7d

2020-11-23 Thread kernel test robot 
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
 staging-next
branch HEAD: 03c1136af504bbc2cabda76af6b27fd5f7cf8a7d  Merge 5.10-rc5 into 
staging-testing

elapsed time: 723m

configs tested: 133
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
m68k  hp300_defconfig
arm bcm2835_defconfig
sh   alldefconfig
m68k apollo_defconfig
shecovec24-romimage_defconfig
powerpc mpc832x_mds_defconfig
xtensa virt_defconfig
sh  r7780mp_defconfig
arm   netwinder_defconfig
xtensa  defconfig
armu300_defconfig
arm nhk8815_defconfig
sh   allmodconfig
powerpc  cm5200_defconfig
arm  badge4_defconfig
powerpc tqm8540_defconfig
microblaze  mmu_defconfig
arm  simpad_defconfig
x86_64   allyesconfig
shapsh4ad0a_defconfig
xtensa  iss_defconfig
powerpc skiroot_defconfig
powerpc  makalu_defconfig
powerpcicon_defconfig
arm cm_x300_defconfig
arm64alldefconfig
mips tb0226_defconfig
powerpc  iss476-smp_defconfig
powerpc akebono_defconfig
arm s3c6400_defconfig
sparcalldefconfig
mips   ip32_defconfig
sh   se7721_defconfig
powerpc  ep88xc_defconfig
c6x dsk6455_defconfig
mipsqi_lb60_defconfig
arc nsimosci_hs_defconfig
riscvallmodconfig
mips   gcw0_defconfig
powerpc   bluestone_defconfig
mips  fuloong2e_defconfig
powerpc   lite5200b_defconfig
mips  ath79_defconfig
arm hackkit_defconfig
mipsar7_defconfig
armrealview_defconfig
arm  footbridge_defconfig
arm   mainstone_defconfig
sparc64  alldefconfig
arm assabet_defconfig
arm  colibri_pxa270_defconfig
powerpc   motionpro_defconfig
powerpc  chrp32_defconfig
sh  rsk7269_defconfig
mipsmalta_qemu_32r6_defconfig
arm rpc_defconfig
powerpc pseries_defconfig
xtensa  audio_kc705_defconfig
mips   rbtx49xx_defconfig
armmps2_defconfig
c6xevmc6474_defconfig
armspear3xx_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a004-20201123
i386 randconfig-a003-20201123
i386

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Miguel Ojeda 
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
 wrote:
>
> Well, I used git.  It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.

I can see ~10k insertions over ~1k commits and 15 years that mention a
fallthrough in the entire repo. That is including some commits (like
the biggest one, 960 insertions) that have nothing to do with C
fallthrough. A single kernel release has an order of magnitude more
changes than this...

But if we do the math, for an author, at even 1 minute per line change
and assuming nothing can be automated at all, it would take 1 month of
work. For maintainers, a couple of trivial lines is noise compared to
many other patches.

In fact, this discussion probably took more time than the time it
would take to review the 200 lines. :-)

> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129

Accepting trivial and useful 1-line patches is not what makes a
voluntary maintainer quit... Thankless work with demanding deadlines is.

> The whole crux of your argument seems to be maintainers' time isn't
> important so we should accept all trivial patches

I have not said that, at all. In fact, I am a voluntary one and I
welcome patches like this. It takes very little effort on my side to
review and it helps the kernel overall. Paid maintainers are the ones
that can take care of big features/reviews.

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

I understand your point, but you were the one putting it in terms of a
junior FTE. In my view, 1 month-work (worst case) is very much worth
removing a class of errors from a critical codebase.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

That may very well be true, but I don't feel anybody has devalued
maintainers in this discussion.

Cheers,
Miguel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5 08/11] input: raspberrypi-ts: Release firmware handle when not needed

2020-11-23 Thread Nicolas Saenz Julienne 
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v3:
 - Release firmware handle in probe function

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/input/touchscreen/raspberrypi-ts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/raspberrypi-ts.c 
b/drivers/input/touchscreen/raspberrypi-ts.c
index ef6aaed217cf..5000f5fd9ec3 100644
--- a/drivers/input/touchscreen/raspberrypi-ts.c
+++ b/drivers/input/touchscreen/raspberrypi-ts.c
@@ -160,7 +160,7 @@ static int rpi_ts_probe(struct platform_device *pdev)
touchbuf = (u32)ts->fw_regs_phys;
error = rpi_firmware_property(fw, RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF,
  , sizeof(touchbuf));
-
+   rpi_firmware_put(fw);
if (error || touchbuf != 0) {
dev_warn(dev, "Failed to set touchbuf, %d\n", error);
return error;
-- 
2.29.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5 04/11] gpio: raspberrypi-exp: Release firmware handle on unbind

2020-11-23 Thread Nicolas Saenz Julienne 
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 
Acked-by: Bartosz Golaszewski 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/gpio/gpio-raspberrypi-exp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-raspberrypi-exp.c 
b/drivers/gpio/gpio-raspberrypi-exp.c
index bb100e0124e6..64a552ecc2ad 100644
--- a/drivers/gpio/gpio-raspberrypi-exp.c
+++ b/drivers/gpio/gpio-raspberrypi-exp.c
@@ -208,7 +208,7 @@ static int rpi_exp_gpio_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   fw = rpi_firmware_get(fw_node);
+   fw = devm_rpi_firmware_get(>dev, fw_node);
of_node_put(fw_node);
if (!fw)
return -EPROBE_DEFER;
-- 
2.29.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5 05/11] reset: raspberrypi: Release firmware handle on unbind

2020-11-23 Thread Nicolas Saenz Julienne 
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/reset/reset-raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/reset/reset-raspberrypi.c 
b/drivers/reset/reset-raspberrypi.c
index 02f59c06f69b..fa23db554bcf 100644
--- a/drivers/reset/reset-raspberrypi.c
+++ b/drivers/reset/reset-raspberrypi.c
@@ -82,7 +82,7 @@ static int rpi_reset_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   fw = rpi_firmware_get(np);
+   fw = devm_rpi_firmware_get(>dev, np);
of_node_put(np);
if (!fw)
return -EPROBE_DEFER;
-- 
2.29.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5 11/11] pwm: Add Raspberry Pi Firmware based PWM bus

2020-11-23 Thread Nicolas Saenz Julienne 
Adds support to control the PWM bus available in official Raspberry Pi
PoE HAT. Only RPi's co-processor has access to it, so commands have to
be sent through RPi's firmware mailbox interface.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v3:
 - Rename compatible string to be more explicit WRT to bus's limitations

Changes since v2:
 - Use devm_rpi_firmware_get()
 - Rename driver
 - Small cleanups

Changes since v1:
 - Use default pwm bindings and get rid of xlate() function
 - Correct spelling errors
 - Correct apply() function
 - Round values
 - Fix divisions in arm32 mode
 - Small cleanups

 drivers/pwm/Kconfig   |   9 ++
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-raspberrypi-poe.c | 216 ++
 3 files changed, 226 insertions(+)
 create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 0937e1c047ac..75e2344703b3 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -423,6 +423,15 @@ config PWM_PXA
  To compile this driver as a module, choose M here: the module
  will be called pwm-pxa.
 
+config PWM_RASPBERRYPI_POE
+   tristate "Raspberry Pi Firwmware PoE Hat PWM support"
+   # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
+   # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
+   depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && 
!RASPBERRYPI_FIRMWARE)
+   help
+ Enable Raspberry Pi firmware controller PWM bus used to control the
+ official RPI PoE hat
+
 config PWM_RCAR
tristate "Renesas R-Car PWM support"
depends on ARCH_RENESAS || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 18b89d7fd092..ed28d7bd4c64 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
 obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
 obj-$(CONFIG_PWM_PCA9685)  += pwm-pca9685.o
 obj-$(CONFIG_PWM_PXA)  += pwm-pxa.o
+obj-$(CONFIG_PWM_RASPBERRYPI_POE)  += pwm-raspberrypi-poe.o
 obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o
 obj-$(CONFIG_PWM_RENESAS_TPU)  += pwm-renesas-tpu.o
 obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
diff --git a/drivers/pwm/pwm-raspberrypi-poe.c 
b/drivers/pwm/pwm-raspberrypi-poe.c
new file mode 100644
index ..24b498839fcc
--- /dev/null
+++ b/drivers/pwm/pwm-raspberrypi-poe.c
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Nicolas Saenz Julienne 
+ * For more information on Raspberry Pi's PoE hat see:
+ * https://www.raspberrypi.org/products/poe-hat/
+ *
+ * Limitations:
+ *  - No disable bit, so a disabled PWM is simulated by duty_cycle 0
+ *  - Only normal polarity
+ *  - Fixed 12.5 kHz period
+ *
+ * The current period is completed when HW is reconfigured.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define RPI_PWM_MAX_DUTY   255
+#define RPI_PWM_PERIOD_NS  8 /* 12.5 kHz */
+
+#define RPI_PWM_CUR_DUTY_REG   0x0
+#define RPI_PWM_DEF_DUTY_REG   0x1
+
+struct raspberrypi_pwm {
+   struct rpi_firmware *firmware;
+   struct pwm_chip chip;
+   unsigned int duty_cycle;
+};
+
+struct raspberrypi_pwm_prop {
+   __le32 reg;
+   __le32 val;
+   __le32 ret;
+} __packed;
+
+static inline struct raspberrypi_pwm *to_raspberrypi_pwm(struct pwm_chip *chip)
+{
+   return container_of(chip, struct raspberrypi_pwm, chip);
+}
+
+static int raspberrypi_pwm_set_property(struct rpi_firmware *firmware,
+   u32 reg, u32 val)
+{
+   struct raspberrypi_pwm_prop msg = {
+   .reg = cpu_to_le32(reg),
+   .val = cpu_to_le32(val),
+   };
+   int ret;
+
+   ret = rpi_firmware_property(firmware, RPI_FIRMWARE_SET_POE_HAT_VAL,
+   , sizeof(msg));
+   if (ret)
+   return ret;
+   if (msg.ret)
+   return -EIO;
+
+   return 0;
+}
+
+static int raspberrypi_pwm_get_property(struct rpi_firmware *firmware,
+   u32 reg, u32 *val)
+{
+   struct raspberrypi_pwm_prop msg = {
+   .reg = reg
+   };
+   int ret;
+
+   ret = rpi_firmware_property(firmware, RPI_FIRMWARE_GET_POE_HAT_VAL,
+   , sizeof(msg));
+   if (ret)
+   return ret;
+   if (msg.ret)
+   return -EIO;
+
+   *val = le32_to_cpu(msg.val);
+
+   return 0;
+}
+
+static void raspberrypi_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+   struct raspberrypi_pwm *rpipwm = to_raspberrypi_pwm(chip);
+
+   state->period = RPI_PWM_PERIOD_NS;
+   state->duty_cycle = DIV_ROUND_CLOSEST(rpipwm->duty_cycle *

[PATCH v5 03/11] clk: bcm: rpi: Release firmware handle on unbind

2020-11-23 Thread Nicolas Saenz Julienne 
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/clk/bcm/clk-raspberrypi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c 
b/drivers/clk/bcm/clk-raspberrypi.c
index f89b9cfc4309..dd3b71eafabf 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -314,7 +314,7 @@ static int raspberrypi_clk_probe(struct platform_device 
*pdev)
return -ENOENT;
}
 
-   firmware = rpi_firmware_get(firmware_node);
+   firmware = devm_rpi_firmware_get(>dev, firmware_node);
of_node_put(firmware_node);
if (!firmware)
return -EPROBE_DEFER;
-- 
2.29.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5 10/11] DO NOT MERGE: ARM: dts: Add RPi's official PoE hat support

2020-11-23 Thread Nicolas Saenz Julienne 
This is an example on how to enable the fan on top of RPi's official PoE
hat.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v1:
 - Update patch to use 2 pwm cells

 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index 403bacf986eb..9ae44620c5b8 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -5,6 +5,7 @@
 #include "bcm283x-rpi-usb-peripheral.dtsi"
 
 #include 
+#include 
 
 / {
compatible = "raspberrypi,4-model-b", "brcm,bcm2711";
@@ -68,6 +69,54 @@ sd_vcc_reg: sd_vcc_reg {
enable-active-high;
gpio = < 6 GPIO_ACTIVE_HIGH>;
};
+
+   fan: pwm-fan {
+   compatible = "pwm-fan";
+   cooling-levels = <0 50 150 255>;
+   #cooling-cells = <2>;
+   pwms = < RASPBERRYPI_FIRMWARE_PWM_POE 8>;
+   };
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   trips {
+   threshold: trip-point@0 {
+   temperature = <45000>;
+   hysteresis = <5000>;
+   type = "active";
+   };
+
+   target: trip-point@1 {
+   temperature = <5>;
+   hysteresis = <2000>;
+   type = "active";
+   };
+
+   cpu_hot: cpu_hot@0 {
+   temperature = <55000>;
+   hysteresis = <2000>;
+   type = "active";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <>;
+   cooling-device = < 0 1>;
+   };
+
+   map1 {
+   trip = <>;
+   cooling-device = < 1 2>;
+   };
+
+   map2 {
+   trip = <_hot>;
+   cooling-device = < 2 3>;
+   };
+   };
+   };
+   };
 };
 
  {
@@ -103,6 +152,11 @@ reset: reset {
compatible = "raspberrypi,firmware-reset";
#reset-cells = <1>;
};
+
+   fwpwm: pwm {
+   compatible = "raspberrypi,firmware-poe-pwm";
+   #pwm-cells = <2>;
+   };
 };
 
  {
-- 
2.29.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5 09/11] dt-bindings: pwm: Add binding for RPi firmware PWM bus

2020-11-23 Thread Nicolas Saenz Julienne 
The PWM bus controlling the fan in RPi's official PoE hat can only be
controlled by the board's co-processor.

Signed-off-by: Nicolas Saenz Julienne 
Reviewed-by: Rob Herring 

---

Changes since v4:
 - Rename compatible string to be more explicit with the bus' limitations

Changes since v3:
 - Fix example

Changes since v1:
 - Update bindings to use 2 #pwm-cells

 .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 +++
 .../pwm/raspberrypi,firmware-poe-pwm.h| 13 
 2 files changed, 33 insertions(+)
 create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h

diff --git 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index a2c63c8b1d10..e3664eab0f6a 100644
--- 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -64,6 +64,21 @@ properties:
   - compatible
   - "#reset-cells"
 
+  pwm:
+type: object
+
+properties:
+  compatible:
+const: raspberrypi,firmware-poe-pwm
+
+  "#pwm-cells":
+# See pwm.yaml in this directory for a description of the cells format.
+const: 2
+
+required:
+  - compatible
+  - "#pwm-cells"
+
 additionalProperties: false
 
 required:
@@ -87,5 +102,10 @@ examples:
 compatible = "raspberrypi,firmware-reset";
 #reset-cells = <1>;
 };
+
+pwm: pwm {
+compatible = "raspberrypi,firmware-poe-pwm";
+#pwm-cells = <2>;
+};
 };
 ...
diff --git a/include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h 
b/include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h
new file mode 100644
index ..27c5ce68847b
--- /dev/null
+++ b/include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Nicolas Saenz Julienne
+ * Author: Nicolas Saenz Julienne 
+ */
+
+#ifndef _DT_BINDINGS_RASPBERRYPI_FIRMWARE_PWM_H
+#define _DT_BINDINGS_RASPBERRYPI_FIRMWARE_PWM_H
+
+#define RASPBERRYPI_FIRMWARE_PWM_POE   0
+#define RASPBERRYPI_FIRMWARE_PWM_NUM   1
+
+#endif
-- 
2.29.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5 06/11] soc: bcm: raspberrypi-power: Release firmware handle on unbind

2020-11-23 Thread Nicolas Saenz Julienne 
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/soc/bcm/raspberrypi-power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/bcm/raspberrypi-power.c 
b/drivers/soc/bcm/raspberrypi-power.c
index 5d1aacdd84ef..068715d6e66d 100644
--- a/drivers/soc/bcm/raspberrypi-power.c
+++ b/drivers/soc/bcm/raspberrypi-power.c
@@ -177,7 +177,7 @@ static int rpi_power_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   rpi_domains->fw = rpi_firmware_get(fw_np);
+   rpi_domains->fw = devm_rpi_firmware_get(>dev, fw_np);
of_node_put(fw_np);
if (!rpi_domains->fw)
return -EPROBE_DEFER;
-- 
2.29.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5 01/11] firmware: raspberrypi: Keep count of all consumers

2020-11-23 Thread Nicolas Saenz Julienne 
When unbinding the firmware device we need to make sure it has no
consumers left. Otherwise we'd leave them with a firmware handle
pointing at freed memory.

Keep a reference count of all consumers and introduce rpi_firmware_put()
which will permit automatically decrease the reference count upon
unbinding consumer drivers.

Suggested-by: Uwe Kleine-König 
Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v3:
- Use kref instead of waiting on refcount

 drivers/firmware/raspberrypi.c | 37 +++---
 include/soc/bcm2835/raspberrypi-firmware.h |  2 ++
 2 files changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 30259dc9b805..ed793aef7851 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,8 @@ struct rpi_firmware {
struct mbox_chan *chan; /* The property channel. */
struct completion c;
u32 enabled;
+
+   struct kref consumers;
 };
 
 static DEFINE_MUTEX(transaction_lock);
@@ -225,12 +228,27 @@ static void rpi_register_clk_driver(struct device *dev)
-1, NULL, 0);
 }
 
+static void rpi_firmware_delete(struct kref *kref)
+{
+   struct rpi_firmware *fw = container_of(kref, struct rpi_firmware,
+  consumers);
+
+   mbox_free_channel(fw->chan);
+   kfree(fw);
+}
+
+void rpi_firmware_put(struct rpi_firmware *fw)
+{
+   kref_put(>consumers, rpi_firmware_delete);
+}
+EXPORT_SYMBOL_GPL(rpi_firmware_put);
+
 static int rpi_firmware_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct rpi_firmware *fw;
 
-   fw = devm_kzalloc(dev, sizeof(*fw), GFP_KERNEL);
+   fw = kzalloc(sizeof(*fw), GFP_KERNEL);
if (!fw)
return -ENOMEM;
 
@@ -247,6 +265,7 @@ static int rpi_firmware_probe(struct platform_device *pdev)
}
 
init_completion(>c);
+   kref_init(>consumers);
 
platform_set_drvdata(pdev, fw);
 
@@ -275,25 +294,35 @@ static int rpi_firmware_remove(struct platform_device 
*pdev)
rpi_hwmon = NULL;
platform_device_unregister(rpi_clk);
rpi_clk = NULL;
-   mbox_free_channel(fw->chan);
+
+   rpi_firmware_put(fw);
 
return 0;
 }
 
 /**
- * rpi_firmware_get - Get pointer to rpi_firmware structure.
  * @firmware_node:Pointer to the firmware Device Tree node.
  *
+ * The reference to rpi_firmware has to be released with rpi_firmware_put().
+ *
  * Returns NULL is the firmware device is not ready.
  */
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node)
 {
struct platform_device *pdev = of_find_device_by_node(firmware_node);
+   struct rpi_firmware *fw;
 
if (!pdev)
return NULL;
 
-   return platform_get_drvdata(pdev);
+   fw = platform_get_drvdata(pdev);
+   if (!fw)
+   return NULL;
+
+   if (!kref_get_unless_zero(>consumers))
+   return NULL;
+
+   return fw;
 }
 EXPORT_SYMBOL_GPL(rpi_firmware_get);
 
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
b/include/soc/bcm2835/raspberrypi-firmware.h
index cc9cdbc66403..fdfef7fe40df 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -140,6 +140,7 @@ int rpi_firmware_property(struct rpi_firmware *fw,
  u32 tag, void *data, size_t len);
 int rpi_firmware_property_list(struct rpi_firmware *fw,
   void *data, size_t tag_size);
+void rpi_firmware_put(struct rpi_firmware *fw);
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node);
 #else
 static inline int rpi_firmware_property(struct rpi_firmware *fw, u32 tag,
@@ -154,6 +155,7 @@ static inline int rpi_firmware_property_list(struct 
rpi_firmware *fw,
return -ENOSYS;
 }
 
+static inline void rpi_firmware_put(struct rpi_firmware *fw) { }
 static inline struct rpi_firmware *rpi_firmware_get(struct device_node 
*firmware_node)
 {
return NULL;
-- 
2.29.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5 07/11] staging: vchiq: Release firmware handle on unbind

2020-11-23 Thread Nicolas Saenz Julienne 
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
interface when unbinding the device.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Use devm_rpi_firmware_get(), instead of remove function

 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index f500a7043805..6c196cade4a0 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -2732,7 +2732,7 @@ static int vchiq_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   drvdata->fw = rpi_firmware_get(fw_node);
+   drvdata->fw = devm_rpi_firmware_get(>dev, fw_node);
of_node_put(fw_node);
if (!drvdata->fw)
return -EPROBE_DEFER;
-- 
2.29.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5 02/11] firmware: raspberrypi: Introduce devm_rpi_firmware_get()

2020-11-23 Thread Nicolas Saenz Julienne 
It'll simplify the firmware handling for most consumers.

Suggested-by: Bartosz Golaszewski 
Signed-off-by: Nicolas Saenz Julienne 
---

Changes since v4:
 - Rearrange function calls for clarity, same functionality

Changes since v2:
- Create devm_rpi_firmware_get()

 drivers/firmware/raspberrypi.c | 29 ++
 include/soc/bcm2835/raspberrypi-firmware.h |  8 ++
 2 files changed, 37 insertions(+)

diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index ed793aef7851..e2a5f6f59357 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -243,6 +243,13 @@ void rpi_firmware_put(struct rpi_firmware *fw)
 }
 EXPORT_SYMBOL_GPL(rpi_firmware_put);
 
+static void devm_rpi_firmware_put(void *data)
+{
+   struct rpi_firmware *fw = data;
+
+   rpi_firmware_put(fw);
+}
+
 static int rpi_firmware_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -326,6 +333,28 @@ struct rpi_firmware *rpi_firmware_get(struct device_node 
*firmware_node)
 }
 EXPORT_SYMBOL_GPL(rpi_firmware_get);
 
+/**
+ * devm_rpi_firmware_get - Get pointer to rpi_firmware structure.
+ * @firmware_node:Pointer to the firmware Device Tree node.
+ *
+ * Returns NULL is the firmware device is not ready.
+ */
+struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+  struct device_node *firmware_node)
+{
+   struct rpi_firmware *fw;
+
+   fw = rpi_firmware_get(firmware_node);
+   if (!fw)
+   return NULL;
+
+   if (devm_add_action_or_reset(dev, devm_rpi_firmware_put, fw))
+   return NULL;
+
+   return fw;
+}
+EXPORT_SYMBOL_GPL(devm_rpi_firmware_get);
+
 static const struct of_device_id rpi_firmware_of_match[] = {
{ .compatible = "raspberrypi,bcm2835-firmware", },
{},
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h 
b/include/soc/bcm2835/raspberrypi-firmware.h
index fdfef7fe40df..73ad784fca96 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -142,6 +142,8 @@ int rpi_firmware_property_list(struct rpi_firmware *fw,
   void *data, size_t tag_size);
 void rpi_firmware_put(struct rpi_firmware *fw);
 struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node);
+struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+  struct device_node *firmware_node);
 #else
 static inline int rpi_firmware_property(struct rpi_firmware *fw, u32 tag,
void *data, size_t len)
@@ -160,6 +162,12 @@ static inline struct rpi_firmware *rpi_firmware_get(struct 
device_node *firmware
 {
return NULL;
 }
+
+static inline struct rpi_firmware *devm_rpi_firmware_get(struct device *dev,
+   struct device_node *firmware_node)
+{
+   return NULL;
+}
 #endif
 
 #endif /* __SOC_RASPBERRY_FIRMWARE_H__ */
-- 
2.29.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5 00/11] Raspberry Pi PoE HAT fan support

2020-11-23 Thread Nicolas Saenz Julienne 
The aim of this series is to add support to the fan found on RPi's PoE
HAT. Some commentary on the design can be found below. But the imporant
part to the people CC'd here not involved with PWM is that, in order to
achieve this properly, we also have to fix the firmware interface the
driver uses to communicate with the PWM bus (and many other low level
functions). Specifically, we have to make sure the firmware interface
isn't unbound while consumers are still up. So, patch #1 & #2 introduce
reference counting in the firwmware interface driver and patches #3 to
#8 update all firmware users. Patches #9 to #11 introduce the new PWM
driver.

I sent everything as a single series as the final version of the PWM
drivers depends on the firwmare fixes, but I'll be happy to split this
into two separate series if you think it's better.

--- Original cover letter below ---

This series aims at adding support to RPi's official PoE HAT fan[1].

The HW setup is the following:

| Raspberry Pi   | PoE HAT|
 arm core -> Mailbox -> RPi co-processor -> I2C -> Atmel MCU -> PWM -> FAN

The arm cores have only access to the mailbox interface, as i2c0, even if
physically accessible, is to be used solely by the co-processor
(VideoCore 4/6).

This series implements a PWM bus, and has pwm-fan sitting on top of it as per
this discussion: https://lkml.org/lkml/2018/9/2/486. Although this design has a
series of shortcomings:

- It depends on a DT binding: it's not flexible if a new hat shows up with new
  functionality, we're not 100% sure we'll be able to expand it without
  breaking backwards compatibility. But without it we can't make use of DT
  thermal-zones, which IMO is overkill.

- We're using pwm-fan, writing a hwmon driver would, again, give us more
  flexibility, but it's not really needed at the moment.

I personally think that it's not worth the effort, it's unlikely we'll get
things right in advance. And ultimately, if the RPi people come up with
something new, we can always write a new driver/bindings from scratch (as in
not reusing previous code).

That said, I'm more than happy to change things if there is a consensus that
another design will do the trick.

[1] https://www.raspberrypi.org/blog/introducing-power-over-ethernet-poe-hat/

---

Changes since v4:
 - Cleanup devm calls
 - Rename compatible string so it's unique to the PoE HAT

Changes since v3:
 - Split first patch, #1 introduces refcount, then #2 the devm function
 - Fix touchscreen function
 - Use kref

Changes since v2:
 - Introduce devm_rpi_firmware_get()
 - Small cleanups in PWM driver

Changes since v1:
 - Address PWM driver changes
 - Fix binding, now with 2 cells

Nicolas Saenz Julienne (11):
  firmware: raspberrypi: Keep count of all consumers
  firmware: raspberrypi: Introduce devm_rpi_firmware_get()
  clk: bcm: rpi: Release firmware handle on unbind
  gpio: raspberrypi-exp: Release firmware handle on unbind
  reset: raspberrypi: Release firmware handle on unbind
  soc: bcm: raspberrypi-power: Release firmware handle on unbind
  staging: vchiq: Release firmware handle on unbind
  input: raspberrypi-ts: Release firmware handle when not needed
  dt-bindings: pwm: Add binding for RPi firmware PWM bus
  DO NOT MERGE: ARM: dts: Add RPi's official PoE hat support
  pwm: Add Raspberry Pi Firmware based PWM bus

 .../arm/bcm/raspberrypi,bcm2835-firmware.yaml |  20 ++
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts |  54 +
 drivers/clk/bcm/clk-raspberrypi.c |   2 +-
 drivers/firmware/raspberrypi.c|  66 +-
 drivers/gpio/gpio-raspberrypi-exp.c   |   2 +-
 drivers/input/touchscreen/raspberrypi-ts.c|   2 +-
 drivers/pwm/Kconfig   |   9 +
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-raspberrypi-poe.c | 216 ++
 drivers/reset/reset-raspberrypi.c |   2 +-
 drivers/soc/bcm/raspberrypi-power.c   |   2 +-
 .../interface/vchiq_arm/vchiq_arm.c   |   2 +-
 .../pwm/raspberrypi,firmware-poe-pwm.h|  13 ++
 include/soc/bcm2835/raspberrypi-firmware.h|  10 +
 14 files changed, 391 insertions(+), 10 deletions(-)
 create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c
 create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h

-- 
2.29.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 01/11] firmware: raspberrypi: Keep count of all consumers

2020-11-23 Thread Nicolas Saenz Julienne 
On Thu, 2020-11-12 at 23:26 -0800, Dmitry Torokhov wrote:
> On Thu, Nov 12, 2020 at 07:52:14PM +0200, Andy Shevchenko wrote:
> > On Thu, Nov 12, 2020 at 6:40 PM Nicolas Saenz Julienne
> >  wrote:
> > > 
> > > When unbinding the firmware device we need to make sure it has no
> > > consumers left. Otherwise we'd leave them with a firmware handle
> > > pointing at freed memory.
> > > 
> > > Keep a reference count of all consumers and introduce rpi_firmware_put()
> > > which will permit automatically decrease the reference count upon
> > > unbinding consumer drivers.
> > 
> > ...
> > 
> > >  /**
> > > - * rpi_firmware_get - Get pointer to rpi_firmware structure.
> > >   * @firmware_node:Pointer to the firmware Device Tree node.
> > >   *
> > > + * The reference to rpi_firmware has to be released with 
> > > rpi_firmware_put().
> > > + *
> > >   * Returns NULL is the firmware device is not ready.
> > >   */
> > >  struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node)
> > >  {
> > > struct platform_device *pdev = 
> > > of_find_device_by_node(firmware_node);
> > > +   struct rpi_firmware *fw;
> > > 
> > > if (!pdev)
> > > return NULL;
> > > 
> > > -   return platform_get_drvdata(pdev);
> > > +   fw = platform_get_drvdata(pdev);
> > > +   if (!fw)
> > > +   return NULL;
> > > +
> > > +   if (!kref_get_unless_zero(>consumers))
> > > +   return NULL;
> > 

Hi Andy, Dimitry,

> > Don't we have a more traditional way of doing this, i.e.
> > try_module_get() coupled with get_device() ?
> 
> get_device() will make sure that device is there, but gives no
> assurances that device is bound to a driver, so it will not help with
> the racy access to firmware via platform_get_drvdata() call.

I also looked at using get/put_device() just as a means for refcounting (i.e.
replacing fw->consumers), but I can't make it work either. I'd need a way to
hook up into one of the struct device_ktype release() functions. AFAIK it's not
possible for private uses like this.

IIUC the way to do this would be to bypass platform device and create a special
device class/bus for RPi's firmware dependent devices (I could pretty much copy
SCMI's implementation), but I fear that's overkill.

So, for now I'll stick with the kref based implementation, I'll be happy to
change it if you find a better solution. :)

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Joe Perches 
On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
> 
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
> 
> And burn out:
> 
> http://antirez.com/news/129

https://www.wired.com/story/open-source-coders-few-tired/

> What I'm actually trying to articulate is a way of measuring value of
> the patch vs cost ... it has nothing really to do with who foots the
> actual bill.

It's unclear how to measure value in consistency.

But one way that costs can be reduced is by automation and _not_
involving maintainers when the patch itself is provably correct.

> One thesis I'm actually starting to formulate is that this continual
> devaluing of maintainers is why we have so much difficulty keeping and
> recruiting them.

The linux kernel has something like 1500 different maintainers listed
in the MAINTAINERS file.  That's not a trivial number.

$ git grep '^M:' MAINTAINERS | sort | uniq -c | wc -l
1543
$ git grep '^M:' MAINTAINERS| cut -f1 -d'<' | sort | uniq -c | wc -l
1446

I think the question you are asking is about trust and how it
effects development.

And back to that wired story, the actual number of what you might
be considering to be maintainers is likely less than 10% of the
listed numbers above.


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread James Bottomley 
On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
>  wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches.  Let's be conservative and assume the producer worked
> > about 30% on the series and it takes about 5-10 minutes per patch
> > to review, merge and for others to rework existing series.  So
> > let's say it's cost a person year of a relatively junior engineer
> > producing the patches and say 100h of review and application
> > time.  The latter is likely the big ticket item because it's what
> > we have in least supply in the kernel (even though it's 20x vs the
> > producer time).
> 
> How are you arriving at such numbers? It is a total of ~200 trivial
> lines.

Well, I used git.  It says that as of today in Linus' tree we have 889
patches related to fall throughs and the first series went in in
october 2017 ... ignoring a couple of outliers back to February.

> > It's not about the risk of the changes it's about the cost of
> > implementing them.  Even if you discount the producer time (which
> > someone gets to pay for, and if I were the engineering manager, I'd
> > be unhappy about), the review/merge/rework time is pretty
> > significant in exchange for six minor bug fixes.  Fine, when a new
> > compiler warning comes along it's certainly reasonable to see if we
> > can benefit from it and the fact that the compiler people think
> > it's worthwhile is enough evidence to assume this initially.  But
> > at some point you have to ask whether that assumption is supported
> > by the evidence we've accumulated over the time we've been using
> > it.  And if the evidence doesn't support it perhaps it is time to
> > stop the experiment.
> 
> Maintainers routinely review 1-line trivial patches, not to mention
> internal API changes, etc.

We're also complaining about the inability to recruit maintainers:

https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/

And burn out:

http://antirez.com/news/129

The whole crux of your argument seems to be maintainers' time isn't
important so we should accept all trivial patches ... I'm pushing back
on that assumption in two places, firstly the valulessness of the time
and secondly that all trivial patches are valuable.

> If some company does not want to pay for that, that's fine, but they
> don't get to be maintainers and claim `Supported`.

What I'm actually trying to articulate is a way of measuring value of
the patch vs cost ... it has nothing really to do with who foots the
actual bill.

One thesis I'm actually starting to formulate is that this continual
devaluing of maintainers is why we have so much difficulty keeping and
recruiting them.

James



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-23 Thread Miguel Ojeda 
On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
 wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 2/4] staging: media: Introduce NVIDIA Tegra video decoder driver

2020-11-23 Thread Dmitry Osipenko 
23.11.2020 06:07, Ezequiel Garcia пишет:
> On Sat, 21 Nov 2020 at 23:01, Dmitry Osipenko  wrote:
>>
>> 22.11.2020 04:02, Ezequiel Garcia пишет:
>>> Hi Dmitry,
>>>
>> ...
 +++ b/drivers/staging/media/tegra-vde/TODO
 @@ -0,0 +1,4 @@
 +TODO:
 +   - Implement V4L2 API once it gains support for stateless decoders.
 +
 +Contact: Dmitry Osipenko 
>>>
>>> The API for H264 stateless decoding is ready.
>>> See https://lkml.org/lkml/2020/11/18/795.
>>
>> Hello Ezequiel,
>>
>> Thank you for the notification! My last attempt at implementing V4L API
>> support was about a year ago and it stopped once I realized that there
>> is no userspace which uses that API. FFMPEG and chromium browser had
>> some kind of V4L support, but it all was oriented at downstream driver
>> stacks, and thus, not usable. Do you know what is the current status?
>>
> 
> The bulk of the API, which relies on the stateless decoder interface [1],
> and H264 stateless V4L2 controls has been ready for some time now,
> and there are various implementations supporting it.
> 
> Chromium supports it [2], and I've tested it on chromebooks,
> through chromeos builds. We haven't tried a non-chromeos build,
> and I would say it's quite some work.
> 
> GStreamer support is available as well. See [3] which should
> work for the latest H264 controls (the ones being moved out of staging).
> 
> LibreELEC developers maintain an Ffmpeg branch [4], I expect it will
> be updated for the latest H264 controls soon, and hopefully merged
> in mainline Ffmpeg.
> 
> GStreamer and Ffmpeg are relatively straightforward to build and test.
> 
> Thanks,
> Ezequiel
> 
> [1] 
> https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-stateless-decoder.html
> [2] https://github.com/chromium/chromium/tree/master/media/gpu/v4l2
> [3] 
> https://gitlab.freedesktop.org/ezequielgarcia/gst-plugins-bad/-/tree/h264_stable_uapi
> [4] https://github.com/Kwiboo/FFmpeg/tree/v4l2-request-hwaccel-4.3.

Alright, thank you.

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 6/7] staging: mt7621-pci: convert to use 'devm_platform_ioremap_resource'

2020-11-23 Thread Sergio Paracuellos 
Instead of getting resources parsing from DT first and remaping
afterwards, this can be done in one step using the kernel function
'devm_platform_ioremap_resource'. Hence, update to use it.

Signed-off-by: Sergio Paracuellos 
---
 drivers/staging/mt7621-pci/pci-mt7621.c | 24 
 1 file changed, 4 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
index a0b3ec51c7d9..4cdaccbcc97c 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -337,28 +337,18 @@ static int mt7621_pci_parse_request_of_pci_ranges(struct 
pci_host_bridge *host)
 }
 
 static int mt7621_pcie_parse_port(struct mt7621_pcie *pcie,
- struct device_node *node,
  int slot)
 {
struct mt7621_pcie_port *port;
struct device *dev = pcie->dev;
struct platform_device *pdev = to_platform_device(dev);
-   struct device_node *pnode = dev->of_node;
-   struct resource regs;
char name[10];
-   int err;
 
port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
if (!port)
return -ENOMEM;
 
-   err = of_address_to_resource(pnode, slot + 1, );
-   if (err) {
-   dev_err(dev, "missing \"reg\" property\n");
-   return err;
-   }
-
-   port->base = devm_ioremap_resource(dev, );
+   port->base = devm_platform_ioremap_resource(pdev, slot + 1);
if (IS_ERR(port->base))
return PTR_ERR(port->base);
 
@@ -399,17 +389,11 @@ static int mt7621_pcie_parse_port(struct mt7621_pcie 
*pcie,
 static int mt7621_pcie_parse_dt(struct mt7621_pcie *pcie)
 {
struct device *dev = pcie->dev;
+   struct platform_device *pdev = to_platform_device(dev);
struct device_node *node = dev->of_node, *child;
-   struct resource regs;
int err;
 
-   err = of_address_to_resource(node, 0, );
-   if (err) {
-   dev_err(dev, "missing \"reg\" property\n");
-   return err;
-   }
-
-   pcie->base = devm_ioremap_resource(dev, );
+   pcie->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(pcie->base))
return PTR_ERR(pcie->base);
 
@@ -425,7 +409,7 @@ static int mt7621_pcie_parse_dt(struct mt7621_pcie *pcie)
 
slot = PCI_SLOT(err);
 
-   err = mt7621_pcie_parse_port(pcie, child, slot);
+   err = mt7621_pcie_parse_port(pcie, slot);
if (err) {
of_node_put(child);
return err;
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/7] staging: mt7621-pci: review 'pci_host_bridge' assigned variables

2020-11-23 Thread Sergio Paracuellos 
PCI kernel apis now set some variables related with pci_host_bridge
by default and it is not necessary to setup them in driver code.
Host bridge parent device is set by default to the platform device
and 'swizzle_irq' is also set to its default function. These two
are not necessary to be set here. Hence remove them.

Signed-off-by: Sergio Paracuellos 
---
 drivers/staging/mt7621-pci/pci-mt7621.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 1f9e75db5298..98569d9b70f2 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -654,10 +654,8 @@ static int mt7621_pcie_register_host(struct 
pci_host_bridge *host,
struct mt7621_pcie *pcie = pci_host_bridge_priv(host);
 
list_splice_init(res, >windows);
-   host->dev.parent = pcie->dev;
host->ops = _pci_ops;
host->map_irq = mt7621_map_irq;
-   host->swizzle_irq = pci_common_swizzle;
host->sysdata = pcie;
 
return pci_host_probe(host);
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/7] staging: mt7621-pci: remove 'offset' with mem and io resource sizes

2020-11-23 Thread Sergio Paracuellos 
Offset contains resources size for both io and memory resources.
Those fields are directly initialized to zero and set up using
'pci_add_resource_offset' function. Instead of doing that remove
them and use directly function 'pci_add_resource' where zero is
passed directly to its internal call to 'pci_add_resource_offset'.

Signed-off-by: Sergio Paracuellos 
---
 drivers/staging/mt7621-pci/pci-mt7621.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 3e8dddf5ec79..219b35937285 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -117,7 +117,6 @@ struct mt7621_pcie_port {
  * @base: IO Mapped Register Base
  * @io: IO resource
  * @mem: non-prefetchable memory resource
- * @offset: IO / Memory offset
  * @dev: Pointer to PCIe device
  * @io_map_base: virtual memory base address for io
  * @ports: pointer to PCIe port information
@@ -130,10 +129,6 @@ struct mt7621_pcie {
struct device *dev;
struct resource io;
struct resource mem;
-   struct {
-   resource_size_t mem;
-   resource_size_t io;
-   } offset;
unsigned long io_map_base;
struct list_head ports;
int irq_map[PCIE_P2P_CNT];
@@ -312,11 +307,9 @@ static int mt7621_pci_parse_request_of_pci_ranges(struct 
mt7621_pcie *pcie)
of_pci_range_to_resource(, node, >io);
pcie->io.start = range.cpu_addr;
pcie->io.end = range.cpu_addr + range.size - 1;
-   pcie->offset.io = 0xUL;
break;
case IORESOURCE_MEM:
of_pci_range_to_resource(, node, >mem);
-   pcie->offset.mem = 0xUL;
break;
}
}
@@ -644,8 +637,8 @@ static int mt7621_pcie_init_virtual_bridges(struct 
mt7621_pcie *pcie)
 static void mt7621_pcie_add_resources(struct mt7621_pcie *pcie,
  struct list_head *res)
 {
-   pci_add_resource_offset(res, >io, pcie->offset.io);
-   pci_add_resource_offset(res, >mem, pcie->offset.mem);
+   pci_add_resource(res, >io);
+   pci_add_resource(res, >mem);
 }
 
 static int mt7621_pcie_register_host(struct pci_host_bridge *host,
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 7/7] staging: mt7621-pci: remove 'RALINK_PCI_IMBASEBAR0_ADDR' register

2020-11-23 Thread Sergio Paracuellos 
Register 'RALINK_PCI_IMBASEBAR0_ADDR' contains internal memory
base address for BAR0. We don't really need to write anything
there at all since its initial value contains always a desired
valid value. Hence remove register definition and related code.

Signed-off-by: Sergio Paracuellos 
---
 drivers/staging/mt7621-pci/pci-mt7621.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 4cdaccbcc97c..c3532bc138fb 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -68,7 +68,6 @@
 #define MT7621_NEXT_PORT   0x1000
 
 #define RALINK_PCI_BAR0SETUP_ADDR  0x0010
-#define RALINK_PCI_IMBASEBAR0_ADDR 0x0018
 #define RALINK_PCI_ID  0x0030
 #define RALINK_PCI_CLASS   0x0034
 #define RALINK_PCI_SUBID   0x0038
@@ -83,7 +82,6 @@
 #define PCIE_PORT_CLK_EN(x)BIT(24 + (x))
 #define PCIE_PORT_LINKUP   BIT(0)
 
-#define MEMORY_BASE0x0
 #define PERST_MODE_MASKGENMASK(11, 10)
 #define PERST_MODE_GPIOBIT(10)
 #define PERST_DELAY_MS 100
@@ -543,8 +541,6 @@ static void mt7621_pcie_enable_port(struct mt7621_pcie_port 
*port)
/* map 2G DDR region */
pcie_write(pcie, PCIE_BAR_MAP_MAX | PCIE_BAR_ENABLE,
   offset + RALINK_PCI_BAR0SETUP_ADDR);
-   pcie_write(pcie, MEMORY_BASE,
-  offset + RALINK_PCI_IMBASEBAR0_ADDR);
 
/* configure class code and revision ID */
pcie_write(pcie, PCIE_CLASS_CODE | PCIE_REVISION_ID,
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 5/7] staging: mt7621-pci: parse and prepare resources in 'mt7621_pci_parse_request_of_pci_ranges'

2020-11-23 Thread Sergio Paracuellos 
Remove 'mt7621_pcie_add_resources' where resources are added to the host
windows moving this code into the function where all the parsing and
preparing code is being done: 'mt7621_pci_parse_request_of_pci_ranges'.
The memory resource has been properly parsed for the PCI APIs so we
only need to retrieve it and use it in those places we need.

Signed-off-by: Sergio Paracuellos 
---
 drivers/staging/mt7621-pci/pci-mt7621.c | 44 -
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 98569d9b70f2..a0b3ec51c7d9 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -116,7 +116,7 @@ struct mt7621_pcie_port {
  * struct mt7621_pcie - PCIe host information
  * @base: IO Mapped Register Base
  * @io: IO resource
- * @mem: non-prefetchable memory resource
+ * @mem: pointer to non-prefetchable memory resource
  * @dev: Pointer to PCIe device
  * @io_map_base: virtual memory base address for io
  * @ports: pointer to PCIe port information
@@ -128,7 +128,7 @@ struct mt7621_pcie {
void __iomem *base;
struct device *dev;
struct resource io;
-   struct resource mem;
+   struct resource *mem;
unsigned long io_map_base;
struct list_head ports;
int irq_map[PCIE_P2P_CNT];
@@ -256,7 +256,7 @@ static inline void mt7621_control_deassert(struct 
mt7621_pcie_port *port)
 
 static void setup_cm_memory_region(struct mt7621_pcie *pcie)
 {
-   struct resource *mem_resource = >mem;
+   struct resource *mem_resource = pcie->mem;
struct device *dev = pcie->dev;
resource_size_t mask;
 
@@ -286,12 +286,15 @@ static int mt7621_map_irq(const struct pci_dev *pdev, u8 
slot, u8 pin)
return irq;
 }
 
-static int mt7621_pci_parse_request_of_pci_ranges(struct mt7621_pcie *pcie)
+static int mt7621_pci_parse_request_of_pci_ranges(struct pci_host_bridge *host)
 {
+   struct mt7621_pcie *pcie = pci_host_bridge_priv(host);
struct device *dev = pcie->dev;
struct device_node *node = dev->of_node;
struct of_pci_range_parser parser;
+   struct resource_entry *entry;
struct of_pci_range range;
+   LIST_HEAD(res);
 
if (of_pci_range_parser_init(, node)) {
dev_err(dev, "missing \"ranges\" property\n");
@@ -314,14 +317,21 @@ static int mt7621_pci_parse_request_of_pci_ranges(struct 
mt7621_pcie *pcie)
of_pci_range_to_resource(, node, >io);
pcie->io.start = range.cpu_addr;
pcie->io.end = range.cpu_addr + range.size - 1;
-   break;
-   case IORESOURCE_MEM:
-   of_pci_range_to_resource(, node, >mem);
+   set_io_port_base(pcie->io_map_base);
break;
}
}
 
-   set_io_port_base(pcie->io_map_base);
+   entry = resource_list_first_type(>windows, IORESOURCE_MEM);
+   if (!entry) {
+   dev_err(dev, "Cannot get memory resource");
+   return -EINVAL;
+   }
+
+   pcie->mem = entry->res;
+   pci_add_resource(, >io);
+   pci_add_resource(, entry->res);
+   list_splice_init(, >windows);
 
return 0;
 }
@@ -641,19 +651,10 @@ static int mt7621_pcie_init_virtual_bridges(struct 
mt7621_pcie *pcie)
return 0;
 }
 
-static void mt7621_pcie_add_resources(struct mt7621_pcie *pcie,
- struct list_head *res)
-{
-   pci_add_resource(res, >io);
-   pci_add_resource(res, >mem);
-}
-
-static int mt7621_pcie_register_host(struct pci_host_bridge *host,
-struct list_head *res)
+static int mt7621_pcie_register_host(struct pci_host_bridge *host)
 {
struct mt7621_pcie *pcie = pci_host_bridge_priv(host);
 
-   list_splice_init(res, >windows);
host->ops = _pci_ops;
host->map_irq = mt7621_map_irq;
host->sysdata = pcie;
@@ -672,7 +673,6 @@ static int mt7621_pci_probe(struct platform_device *pdev)
struct mt7621_pcie *pcie;
struct pci_host_bridge *bridge;
int err;
-   LIST_HEAD(res);
 
if (!dev->of_node)
return -ENODEV;
@@ -696,7 +696,7 @@ static int mt7621_pci_probe(struct platform_device *pdev)
return err;
}
 
-   err = mt7621_pci_parse_request_of_pci_ranges(pcie);
+   err = mt7621_pci_parse_request_of_pci_ranges(bridge);
if (err) {
dev_err(dev, "Error requesting pci resources from ranges");
return err;
@@ -718,9 +718,7 @@ static int mt7621_pci_probe(struct platform_device *pdev)
 
setup_cm_memory_region(pcie);
 
-   mt7621_pcie_add_resources(pcie, );
-
-   err = mt7621_pcie_register_host(bridge, );
+   err = mt7621_pcie_register_host(bridge);
if (err) {

[PATCH 3/7] staging: mt7621-pci: add comment to clarify IO resource in this driver

2020-11-23 Thread Sergio Paracuellos 
Because IO_SPACE_LIMIT for mips is 0x but this platform uses
PĈI IO resource at 0x001e16. Hence instead of directly use
some more accurate functions from the PCI kernel for this driver
some things must be done in a different way to make things work.
Add this explanation as a comment where the IO resource is parsed
and virtually mapped into memory.

Signed-off-by: Sergio Paracuellos 
---
 drivers/staging/mt7621-pci/pci-mt7621.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 219b35937285..1f9e75db5298 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -298,6 +298,13 @@ static int mt7621_pci_parse_request_of_pci_ranges(struct 
mt7621_pcie *pcie)
return -EINVAL;
}
 
+   /*
+* IO_SPACE_LIMIT for MIPS is 0x but this platform uses IO at
+* upper address 0x001e16 so we have to get the resource from
+* the DT because when it has been requested it failed and has been
+* removed from bridge->dma_ranges and bridge->windows. So parse it
+* and remap it manually to make things work.
+*/
for_each_of_pci_range(, ) {
switch (range.flags & IORESOURCE_TYPE_BITS) {
case IORESOURCE_IO:
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/7] staging: mt7621-pci: update to last kernel APIs and other related minor cleanups

2020-11-23 Thread Sergio Paracuellos 
This patch series updates the driver to use last kernel apis and
other minor cleanup changes related with this changes.

LOC decressed a bit which is always a good thing :)

This serias has been tested in GnuBee PC1 boards resulting in a
working platform.

Best regards,
   Sergio Paracuellos

Sergio Paracuellos (7):
  staging: mt7621-pci: remove bus ranges related code
  staging: mt7621-pci: remove 'offset' with mem and io resource sizes
  staging: mt7621-pci: add comment to clarify IO resource in this driver
  staging: mt7621-pci: review 'pci_host_bridge' assigned variables
  staging: mt7621-pci: parse and prepare resources in
'mt7621_pci_parse_request_of_pci_ranges'
  staging: mt7621-pci: convert to use 'devm_platform_ioremap_resource'
  staging: mt7621-pci: remove 'RALINK_PCI_IMBASEBAR0_ADDR' register

 drivers/staging/mt7621-pci/pci-mt7621.c | 97 -
 1 file changed, 30 insertions(+), 67 deletions(-)

-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/7] staging: mt7621-pci: remove bus ranges related code

2020-11-23 Thread Sergio Paracuellos 
Bus ranges are now discovered by default. Hence remove
its related code from the driver.

Signed-off-by: Sergio Paracuellos 
---
 drivers/staging/mt7621-pci/pci-mt7621.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c 
b/drivers/staging/mt7621-pci/pci-mt7621.c
index 7b38ef9f8560..3e8dddf5ec79 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -117,7 +117,6 @@ struct mt7621_pcie_port {
  * @base: IO Mapped Register Base
  * @io: IO resource
  * @mem: non-prefetchable memory resource
- * @busn: bus range
  * @offset: IO / Memory offset
  * @dev: Pointer to PCIe device
  * @io_map_base: virtual memory base address for io
@@ -131,7 +130,6 @@ struct mt7621_pcie {
struct device *dev;
struct resource io;
struct resource mem;
-   struct resource busn;
struct {
resource_size_t mem;
resource_size_t io;
@@ -299,7 +297,6 @@ static int mt7621_pci_parse_request_of_pci_ranges(struct 
mt7621_pcie *pcie)
struct device_node *node = dev->of_node;
struct of_pci_range_parser parser;
struct of_pci_range range;
-   int err;
 
if (of_pci_range_parser_init(, node)) {
dev_err(dev, "missing \"ranges\" property\n");
@@ -324,15 +321,6 @@ static int mt7621_pci_parse_request_of_pci_ranges(struct 
mt7621_pcie *pcie)
}
}
 
-   err = of_pci_parse_bus_range(node, >busn);
-   if (err < 0) {
-   dev_err(dev, "failed to parse bus ranges property: %d\n", err);
-   pcie->busn.name = node->name;
-   pcie->busn.start = 0;
-   pcie->busn.end = 0xff;
-   pcie->busn.flags = IORESOURCE_BUS;
-   }
-
set_io_port_base(pcie->io_map_base);
 
return 0;
@@ -666,7 +654,6 @@ static int mt7621_pcie_register_host(struct pci_host_bridge 
*host,
struct mt7621_pcie *pcie = pci_host_bridge_priv(host);
 
list_splice_init(res, >windows);
-   host->busnr = pcie->busn.start;
host->dev.parent = pcie->dev;
host->ops = _pci_ops;
host->map_irq = mt7621_map_irq;
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel