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
allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
i386 randconfig-a004-20201123
i386 randconfig-a003-20201123
i386 randconfig-a002-20201123
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
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
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
allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
i386 randconfig-a004-20201123
i386 randconfig-a003-20201123
i386 randconfig-a002-20201123
i386
allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20201123
i386 randconfig-a003-20201123
i386 randconfig-a002-20201123
i386 randconfig-a005-20201123
i386 randconfig-a001
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
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
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
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
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
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
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
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:
-
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
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
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 |
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()
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
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.
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
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
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
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
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
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.
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
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
---
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
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
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
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
33 matches
Mail list logo
