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 me
On Fri, Nov 13, 2020 at 1:40 AM Chuanhong Guo wrote:
>
> On Thu, Nov 12, 2020 at 1:23 PM Sergio Paracuellos
> wrote:
> >
> > To avoid weird behaviour because of some drivers are
> > not using properly clocks we have the CLK_IGNORED_UNUSED, which as you
> > can see is currently being used in my co
On Thu, Nov 12, 2020 at 1:23 PM Sergio Paracuellos
wrote:
>
> To avoid weird behaviour because of some drivers are
> not using properly clocks we have the CLK_IGNORED_UNUSED, which as you
> can see is currently being used in my code. Using that all seems to
> work as expected as it is now.
The wh
12.11.2020 23:01, Mark Brown пишет:
>> But it's not allowed to change voltage of a dummy regulator, is it
>> intentional?
> Of course not, we can't know if the requested new voltage is valid - the
> driver would have to have explict support for handling situations where
> it's not possible to chang
This patch fixes the following:
- Made sure alignment matched open parenthesis.
Signed-off-by: Tabot Kevin
---
drivers/staging/greybus/audio_module.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/greybus/audio_module.c
b/drivers/staging/greybus/audi
12.11.2020 23:43, Thierry Reding пишет:
>> The difference in comparison to using voltage regulator directly is
>> minimal, basically the core-supply phandle is replaced is replaced with
>> a power-domain phandle in a device tree.
> These new power-domain handles would have to be added to devices th
On Thu, Nov 12, 2020 at 10:57:27PM +0300, Dmitry Osipenko wrote:
> 11.11.2020 14:38, Ulf Hansson пишет:
> > On Sun, 8 Nov 2020 at 13:19, Dmitry Osipenko wrote:
> >>
> >> 05.11.2020 18:22, Dmitry Osipenko пишет:
> >>> 05.11.2020 12:45, Ulf Hansson пишет:
> >>> ...
> I need some more time to re
On Thu, Nov 12, 2020 at 10:16:14PM +0300, Dmitry Osipenko wrote:
> 12.11.2020 20:16, Mark Brown пишет:
> > On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:
> >> Also, some device-trees won't have that regulator anyways because board
> >> schematics isn't available, and thus, we can
11.11.2020 14:38, Ulf Hansson пишет:
> On Sun, 8 Nov 2020 at 13:19, Dmitry Osipenko wrote:
>>
>> 05.11.2020 18:22, Dmitry Osipenko пишет:
>>> 05.11.2020 12:45, Ulf Hansson пишет:
>>> ...
I need some more time to review this, but just a quick check found a
few potential issues...
>>>
>>>
12.11.2020 20:16, Mark Brown пишет:
> On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:
>> 11.11.2020 14:55, Mark Brown пишет:
>>> On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
>
I already changed that code to use regulator_get_optional() for v2.
>
>>> That
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_
On Thu, Nov 12, 2020 at 5:44 PM Nicolas Saenz Julienne
wrote:
>
> Itroduce devm_rpi_firmware_get(), it'll simplify the firmware handling
> for most consumers.
>
> Suggested-by: Bartosz Golaszewski
> Signed-off-by: Nicolas Saenz Julienne
> ---
>
> Changes since v2:
> - Introduce devm_rpi_firmware
On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:
> 11.11.2020 14:55, Mark Brown пишет:
> > On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
> >> I already changed that code to use regulator_get_optional() for v2.
> > That doesn't look entirely appropriate given tha
11.11.2020 14:55, Mark Brown пишет:
> On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
>> 10.11.2020 23:32, Mark Brown пишет:
>
> + if (!device_property_present(dc->dev, "core-supply"))
> + return;
>
This is a potentially heavy operation, so I think we should
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 v3:
- Fix example
Changes since v1:
- Update bindings to use 2 #pwm-cells
.../arm/bcm/raspberrypi,b
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 v2:
- Use devm_rpi_firmware_get()
- Rename dri
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
Itroduce devm_rpi_firmware_get(), it'll simplify the firmware handling
for most consumers.
Suggested-by: Bartosz Golaszewski
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v2:
- Introduce devm_rpi_firmware_get()
drivers/firmware/raspberrypi.c | 31 +-
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/ar
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.
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 inser
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 ins
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 inser
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
un
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
d
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
Fixes the following W=1 kernel build warning(s):
drivers/net/wimax/i2400m/tx.c:715: warning: Function parameter or member
'i2400m' not described in 'i2400m_tx'
drivers/net/wimax/i2400m/tx.c:964: warning: Function parameter or member
'i2400m' not described in 'i2400m_tx_setup'
drivers/net/wima
Fixes the following W=1 kernel build warning(s):
drivers/net/wimax/i2400m/fw.c:584: warning: Function parameter or member
'i2400m' not described in 'i2400m_bm_cmd'
drivers/net/wimax/i2400m/fw.c:584: warning: Excess function parameter
'returns' description in 'i2400m_bm_cmd'
drivers/net/wimax/
Fixes the following W=1 kernel build warning(s):
drivers/net/wimax/i2400m/control.c:1195: warning: Function parameter or member
'arg' not described in 'i2400m_set_init_config'
drivers/net/wimax/i2400m/control.c:1195: warning: Excess function parameter
'arg_size' description in 'i2400m_set_init
Fixes the following W=1 kernel build warning(s):
drivers/net/wimax/i2400m/netdev.c:583: warning: Function parameter or member
'net_dev' not described in 'i2400m_netdev_setup'
Cc: Greg Kroah-Hartman
Cc: Inaky Perez-Gonzalez
Cc: linux-wi...@intel.com
Cc: "David S. Miller"
Cc: Jakub Kicinski
C
Fixes the following W=1 kernel build warning(s):
drivers/net/wimax/i2400m/fw.c:647: warning: Function parameter or member
'__chunk_len' not described in 'i2400m_download_chunk'
drivers/net/wimax/i2400m/fw.c:647: warning: Excess function parameter
'chunk_len' description in 'i2400m_download_chu
Fixes the following W=1 kernel build warning(s):
drivers/net/wimax/i2400m/driver.c:681: warning: Function parameter or member
'i2400m' not described in 'i2400m_dev_reset_handle'
drivers/net/wimax/i2400m/driver.c:681: warning: Function parameter or member
'reason' not described in 'i2400m_dev_r
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
This is a rebased set that went to Net before the move to Staging.
Lee Jones (6):
staging: net: wimax: i2400m: control: Fix some misspellings in
On Wed, 2020-11-11 at 17:45 -0800, Dmitry Torokhov wrote:
> Hi Nicolas,
>
> On Wed, Nov 04, 2020 at 11:39:33AM +0100, Nicolas Saenz Julienne wrote:
> > Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware
> > interface when unbinding the device.
>
> Unless I am mistaken this d
34 matches
Mail list logo
