On Thu, Apr 18, 2024 at 10:55:39PM +0200, Heiner Kallweit wrote:
> 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
> instantiation") removed the last call to i2c_mux_add_adapter() with a
> non-null class argument. Therefore the class argument can be removed.
>
> Note:
> I will change the subject line to s/comeda/komeda/ when merging it.
Oh, thank you!
signature.asc
Description: PGP signature
value directly to drop
'timeout' which also fixes its wrong type.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display
On Thu, Apr 18, 2024 at 10:55:39PM +0200, Heiner Kallweit wrote:
> 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
> instantiation") removed the last call to i2c_mux_add_adapter() with a
> non-null class argument. Therefore the class argument can be removed.
>
> Note:
> > /* wait the flip take affect.*/
> > - timeout = wait_for_completion_timeout(flip_done, HZ);
> > - if (timeout == 0) {
> > + time_left = wait_for_completion_timeout(flip_done, HZ);
> > + if (time_left == 0) {
>
> Honestly, if the name of the variable is confusing I would get rid
' as a variable to make the code
self explaining.
Fix to the proper variable type 'unsigned long' while here.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda
Hi Easwar,
> Sorry, got excited. :) There were drivers I'd been part of that I specifically
> wanted to fixup, but then the scope grew to other users of algobit.
Well, you got some positive feedback, so that is good.
> > It is true that I changed quite some controller drivers within the i2c
> >
Hello Easwar,
On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of the
>
All former
> users on these platforms have been converted to the SH-Mobile DRM
> driver, using DT.
>
> Suggested-by: Arnd Bergmann
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
signature.asc
Description: PGP signature
On Mon, Nov 13, 2023 at 12:37:15PM +0100, Heiner Kallweit wrote:
> I2C_CLASS_SPD was used to expose the EEPROM content to user space,
> via the legacy eeprom driver. Now that this driver has been removed,
> we can remove I2C_CLASS_SPD support. at24 driver with explicit
> instantiation should be
> I created an immutable branch for this which the buildbots will
> hopefully check over night. I will reply with comments tomorrow when I
> got the buildbot results.
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Thu, Nov 23, 2023 at 10:40:20AM +0100, Heiner Kallweit wrote:
> After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
> olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
> Class-based device auto-detection is a legacy mechanism and shouldn't
> be used in new
> We're not in a hurry. It's just my experience with patch series' affecting
> multiple subsystems that typically the decision was to apply the full
> series via one tree. Also to avoid inquires from maintainers like:
> Shall I take it or are you going to take it?
> Of course there may be
> Preferably this series should be applied via the i2c tree.
Are we in a hurry here, i.e. does it block further development of the
i801 smbus driver? My gut feeling says the patches should rather go via
drm and fbdev trees, but I may be convinced otherwise.
signature.asc
Description: PGP
ozlowski
>
> ---
>
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
I am fine that you take it once all review comments are addressed. Given
that:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
ozlowski
>
> ---
>
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
I am fine that you take it once all review comments are addressed. Given
that:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
Not RCAR, but R-Car.
Signed-off-by: Wolfram Sang
Reviewed-by: Kieran Bingham
Reviewed-by: Geert Uytterhoeven
---
Changes since v2:
* rebased to 6.6
* added Geert's tag (thanks!)
drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi Guenter,
> I didn't (want to) say that. I am perfectly happy with driver specific
> code, and I would personally still very much prefer it. I only wanted to
> suggest that _if_ a generic solution is implemented, it should cover all
> existing use cases and not just this one. But, really, I'd
Hi Guenter,
> > > Reference to Andrew's previous proposal:
> > > https://lore.kernel.org/all/20200914122811.3295678-1-and...@aj.id.au/
> >
> > I do totally agree with Guenter's comment[1], though. This just affects
> > a few drivers and this patch is way too intrusive for the I2C core. The
> >
Hi,
thanks for this series!
> Reference to Andrew's previous proposal:
> https://lore.kernel.org/all/20200914122811.3295678-1-and...@aj.id.au/
I do totally agree with Guenter's comment[1], though. This just affects
a few drivers and this patch is way too intrusive for the I2C core. The
later
Since commit ab78029ecc34 ("drivers/pinctrl: grab default handles from
device core"), we can rely on device core for setting the default pins.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/
Not RCAR, but R-Car.
Signed-off-by: Wolfram Sang
Reviewed-by: Kieran Bingham
---
Changes since v1:
* rebased to 6.6-rc2
* added tag from Kieran (Thanks!)
drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
Not RCAR, but R-Car.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h
b/drivers/gpu/drm/renesas/rcar-du/rcar_du_plane.h
index f9893d7d6dfc
> > Without of_node, devm_clk_get() and friends falls back to registered
> > clkdevs. So you could call clk_register_clkdev() from within the
> > PMIC driver, and can keep on using devm_clk_get_optional() in the
> > ISL1208 driver.
>
> Seriously, how many hacks are we piling ? :-)
For this
Hi everyone,
> Perhaps we should first think through what an ancillary device really
> is. My understanding is that it is used to talk to secondary addresses
> of a multi-address I2C slave device.
As I mentioned somewhere before, this is not the case. Ancillary devices
are when one *driver*
Hi Geert,
> > Would this binding allow to not use the RTC if the second reg is
> > missing? What are the advantages of not enabling RTC? Saving power?
>
> It doesn't work if there is no clock?
Maybe I am confusing something now, but if the RTC _needs_ to be
enabled, then why we don't do it
Hi Biju,
> DT-Maintainers suggestion:
> [1]
> raa215300: pmic@12 {
> compatible = "renesas,raa215300";
> reg = <0x12>, <0x6f>;
> reg-names = "main", "rtc";
>
> clocks = <>;
> clock-names = "xin";
> /* Add Optional shared IRQ resource and share it to child and
Hi all,
sorry for not being able to chime in earlier.
> In Biju's particular use case, the i2c device responds to two addresses,
> which is the standard i2c ancillary use case. However, what's special
Not quite. ancillary is used when a *driver* needs to take care of two
addresses. We already
> Wolfram: time to chime in ;-)
I'll have a look this week.
signature.asc
Description: PGP signature
-by: Wolfram Sang
Reviewed-by: Kieran Bingham
---
This is the last ES1 bit remaining, would be awesome if it could go
soon.
Changes since v1:
* rebased to 6.4-rc1 (no code updates needed)
* added Kieran's tag (thanks!)
* mention in commit message that ES1 doesn't even boot anymore
drivers/gpu/drm
!
Wolfram Sang (11):
iommu/ipmmu-vmsa: remove R-Car H3 ES1.* handling
drm: rcar-du: remove R-Car H3 ES1.* workarounds
media: rcar-vin: remove R-Car H3 ES1.* handling
media: rcar-vin: csi2: remove R-Car H3 ES1.* handling
media: renesas: fdp1: remove R-Car H3 ES1.* handling
thermal
-by: Wolfram Sang
---
Please apply individually per subsystem. There are no dependencies and the SoC
doesn't boot anymore since v6.3-rc1.
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 37 ++--
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 48 --
drivers/gpu/drm/rcar-du
ed and fixed.
>
> Signed-off-by: Rob Herring
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
> Yes, that's the plan. We're collecting the various patches people have sent
> in for arch/sh, review and test them and apply them.
>
> My test board is running the latest kernel now, so I can test new patches,
> too.
I am just witnessing this development, but I want to say thanks for your
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wolfram Sang
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wolfram Sang
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.
Link:
https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/
Signed-off-by: Wolfram Sang
> As some conflicts are expected I sent this early after -rc1 such that it
> can be included early into next and be put on an immutable branch for
> subsystems to resolve merge conflicts.
I pushed the series out now, so it should hit -next tomorrow.
The immutable branch is here:
On Mon, Aug 15, 2022 at 10:02:25AM +0200, Uwe Kleine-König wrote:
> A remove callback that just returns 0 is equivalent to no callback at all
> as can be seen in i2c_device_remove(). So simplify accordingly.
>
> Signed-off-by: Uwe Kleine-König
Applied to an immutable branch, thanks!
On Sun, Aug 07, 2022 at 11:04:54PM +0900, Robin Reckmann wrote:
> Fix i2c transfers using GPI DMA mode for all message types that do not set
> the I2C_M_DMA_SAFE flag (e.g. SMBus "read byte").
>
> In this case a bounce buffer is returned by i2c_get_dma_safe_msg_buf(),
> and it has to synced back
On Sun, Aug 07, 2022 at 11:04:54PM +0900, Robin Reckmann wrote:
> Fix i2c transfers using GPI DMA mode for all message types that do not set
> the I2C_M_DMA_SAFE flag (e.g. SMBus "read byte").
>
> In this case a bounce buffer is returned by i2c_get_dma_safe_msg_buf(),
> and it has to synced back
> I'm getting quite a bunch of unrelated mails because the regex is not the
> best.
I can imagine!
> On the other hand the framework is used in a lot of drivers and I do want to
> be notified when they mess with their interfaces.
Sure thing. I am convinced the regex can be improved to ensure
Hi Christian,
> Maybe call your variable differently. DMA-buf is an inter driver buffer
> sharing frame we use for GPU acceleration and V4L.
>
> It doesn't cause any technical issues, but the maintainer regex now triggers
> on that. So you are CCing people not related to this code in any way.
On Thu, Nov 25, 2021 at 10:23:44PM +0530, Akhil R wrote:
> Add support for the ACPI based device registration so that the driver
> can be also enabled through ACPI table.
>
> This does not include the ACPI support for Tegra VI and DVC I2C.
>
> Signed-off-by: Akhil R
Applied to for-next,
abled.
>
> Signed-off-by: Michael S. Tsirkin
Acked-by: Wolfram Sang # for I2C changes
signature.asc
Description: PGP signature
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/panfrost/panfrost_device.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
ptr =
- platform_get_drvdata(pdev)
+ dev_get_drvdata(d)
<... when != pdev
- >dev
+ d
...>
Kind regards,
Wolfram
Wolfram Sang (9):
dmaengine: stm32-dmamux: simplify getting .driver_data
firmware: meson: simplify getting .driver_data
gpio: xilinx: simplify ge
On Wed, Apr 28, 2021 at 05:57:55PM +0530, Shubhankar Kuranagatti wrote:
> Multi line comment have been aligned starting with a *
> The closing */ has been shifted to a new line.
> Single space replaced with tab space
> This is done to maintain code uniformity.
A step in the right direction but
mo
> Cc: Alexandre Belloni
> Cc: Greg Kroah-Hartman
> Cc: Mark Brown
> Cc: Zhang Rui
> Cc: Daniel Lezcano
> Cc: Wim Van Sebroeck
> Cc: Guenter Roeck
> Signed-off-by: Rob Herring
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
> Hi, this issue is fixed in
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-gt-next=5b11705608898c31a1cae5340555ee60d5a4fa45
>
> And I think the pull request is in
> https://lists.freedesktop.org/archives/intel-gfx/2021-May/267588.html
Thanks for the heads up. So, I'll wait with
oid name clash with pm_ global
> functions
>
> Signed-off-by: Stephen Rothwell
Looks like the proper solution to me. I think this should be added to
the i915 tree. D'accord everyone?
Reviewed-by: Wolfram Sang
Kind regards,
Wolfram
signature.asc
Description: PGP signature
hov
> Acked-by: Krzysztof Kozlowski # for drivers/memory
> Acked-by: Mark Brown
> Acked-by: Dmitry Torokhov
> Acked-by: Linus Walleij
> Signed-off-by: Uwe Kleine-König
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
_
On Tue, Nov 24, 2020 at 12:57:43PM -0600, Bjorn Andersson wrote:
> A combination of recent bug fixes by Doug Anderson and the proper
> definition of iommu streams means that this hack is no longer needed.
> Let's clean up the code by reverting '127068abe85b ("i2c: qcom-geni:
> Disable DMA
alsa-de...@alsa-project.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@lists.infradead.org
> Cc: linux-ser...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
__
constant source of review issues.
>
> Signed-off-by: Rob Herring
I trust you, so for I2C:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index e32ef3f01fe8..b13b1cbcac29 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -1785,7 +1785,7 @@ static int i801_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
..@alsa-project.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@lists.infradead.org
> Cc: net...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-ser...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring
I trust you guys in figuring out the details, so fo
On Tue, Jul 07, 2020 at 11:04:03AM -0700, Randy Dunlap wrote:
> Drop doubled word "new".
>
> Signed-off-by: Randy Dunlap
For the record:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
___
dri-devel mai
On Tue, Jul 07, 2020 at 11:04:03AM -0700, Randy Dunlap wrote:
> Drop doubled word "new".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Wolfram Sang
> Cc: linux-...@vger.kernel.org
Reviewed-by: Wolfram Sang
Hi Alexander,
thanks for trying to fix this, yet I have some doubts.
On Mon, Jun 29, 2020 at 10:31:21PM +0200, Alexander A. Klimov wrote:
> Rationale:
> https://lore.kernel.org/linux-doc/20200626110706.7b5d4...@lwn.net/
I think we need some text here. Clicking on a link to understand what a
On Mon, Jun 15, 2020 at 09:58:09AM +0200, Wolfram Sang wrote:
> I want to remove the above API this cycle, and just a few patches have
> not made it into 5.8-rc1. They have been reviewed and most had been
> promised to get into linux-next, but well, things happen. So, I hope it
module_put() balances try_module_get(), not request_module(). Fix the
error path to match that.
Fixes: 2066facca4c7 ("drm/kms: slave encoder interface.")
Signed-off-by: Wolfram Sang
Reviewed-by: Emil Velikov
---
I'd like to push it via I2C for 5.8-rc2.
drivers/gpu/drm/drm_encoder_s
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
Reviewed-by: Daniel Thompson
---
I'd like to push it via I2C for 5.8-rc2.
drivers/video/backlight/tosa_lcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
minor exception is the media documentation patch which I simply have
missed so far, but it is trivial.
And then, finally, there is the removal of the old API as the final
patch. Phew, that's been a long ride.
I am open for comments, of course.
Happy hacking,
Wolfram
Wolfram Sang (6):
drm
we use this condensed error check.
Signed-off-by: Wolfram Sang
Reviewed-by: Emil Velikov
---
I'd like to push it via I2C for 5.8-rc2.
drivers/gpu/drm/drm_encoder_slave.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b
, the vblank init message is displayed again when the DU driver
is retried. Because the message doesn't really carry a useful
information, I suggest to simply drop it.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/drm_vblank.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm
On Mon, Mar 16, 2020 at 05:39:05PM +0100, Wolfram Sang wrote:
> While converting I2C users to new APIs, I found a refcounting problem in
> the encoder_slave implementation. This series fixes it and converts to
> the new API.
>
> Based on linux-next and only build tested.
>
On Fri, Apr 17, 2020 at 11:14:46AM +0100, Lee Jones wrote:
> On Thu, 26 Mar 2020, Wolfram Sang wrote:
>
> > Move away from the deprecated API and return the shiny new ERRPTR where
> > useful.
> >
> > Signed-off-by: Wolfram Sang
> > ---
> > drivers/
On Fri, Apr 24, 2020 at 05:33:42PM +0200, Maxime Ripard wrote:
> The BCM2711, supported by ARCH_BCM2835, also has a controller by the
> brcmstb driver so let's allow it to be compiled on that platform.
>
> Cc: Kamal Dasu
> Cc: Wolfram Sang
> Cc: bcm-kernel-feedback-l...@broadc
On Fri, Apr 24, 2020 at 10:07:25AM -0700, Florian Fainelli wrote:
>
>
> On 4/24/2020 9:13 AM, Wolfram Sang wrote:
> >
> >> config I2C_BRCMSTB
> >>tristate "BRCM Settop/DSL I2C controller"
> >> - depends on ARCH_BRCMSTB || BMIPS_GENERIC |
> config I2C_BRCMSTB
> tristate "BRCM Settop/DSL I2C controller"
> - depends on ARCH_BRCMSTB || BMIPS_GENERIC || ARCH_BCM_63XX || \
> -COMPILE_TEST
> + depends on ARCH_BCM2835 || ARCH_BRCMSTB || BMIPS_GENERIC || \
> +ARCH_BCM_63XX || COMPILE_TEST
everyone copies the simpler syntax.
>
> Signed-off-by: Rob Herring
Same preamble for my ack as in patch 1:
Acked-by: Wolfram Sang
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists
pts which do transforms on the schema files.
>
> Signed-off-by: Rob Herring
I see that people had comments but I can't judge the topics raised. So,
I trust you guys that you find out when it is good to go and for that,
here is my ack:
Acked-by: Wolfram Sang
signature.asc
Descript
everyone copies the simpler syntax.
>
> Signed-off-by: Rob Herring
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
pts which do transforms on the schema files.
>
> Signed-off-by: Rob Herring
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/ma
> > > > Move away from the deprecated API.
> > > >
> > > > Signed-off-by: Wolfram Sang
> > >
> > > patches 1,6, are:
> > > Acked-by: Alex Deucher
> > Should we commit all to drm-misc-next?
>
> I'm fine to see it go thro
We are deprecating calls which return NULL in favor of new variants which
return an ERR_PTR. Only build tested.
Wolfram Sang (6):
drm/amdgpu: convert to use i2c_new_client_device()
drm/gma500: convert to use i2c_new_client_device()
drm/i2c/sil164: convert to use i2c_new_client_device
Move away from the deprecated API.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/radeon/radeon_atombios.c | 4 ++--
drivers/gpu/drm/radeon/radeon_combios.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/ic.c
b/drivers/gpu
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/i2c/sil164_drv.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/sil164_drv.c b/drivers/gpu/drm/i2c/sil164_drv.c
index
Move away from the deprecated API.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
index ba1bb95a3cf9..0e8018c9aa8e
We are deprecating calls which return NULL in favor of new variants which
return an ERR_PTR. Only build tested.
Wolfram Sang (1):
video: backlight: tosa_lcd: convert to use i2c_new_client_device()
drivers/video/backlight/tosa_lcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/i2c/tda998x_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
b/drivers/gpu/drm
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
---
drivers/video/backlight/tosa_lcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/tosa_lcd.c
b/drivers/video/backlight/tosa_lcd.c
module_put() balances try_module_get(), not request_module(). Fix the
error path to match that.
Fixes: 2066facca4c7 ("drm/kms: slave encoder interface.")
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/drm_encoder_slave.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
While converting I2C users to new APIs, I found a refcounting problem in
the encoder_slave implementation. This series fixes it and converts to
the new API.
Based on linux-next and only build tested.
Wolfram Sang (2):
drm: encoder_slave: fix refcouting error for modules
drm: encoder_slave
we use this condensed error check.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/drm_encoder_slave.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b/drivers/gpu/drm/drm_encoder_slave.c
index d50a7884e69e..e464429d32df 100644
> config I2C_BRCMSTB
> tristate "BRCM Settop/DSL I2C controller"
> depends on ARCH_BRCMSTB || BMIPS_GENERIC || ARCH_BCM_63XX || \
> -COMPILE_TEST
> +COMPILE_TEST || ARCH_BCM2835
Can you please sort if for easier maintenance?
signature.asc
lso tie the AUTO_I2C registers with a
> separate compatible so that we can enable AUTO_I2C if needed in the
> future.
>
> The AUTO_I2C is enabled by default at boot though, so we first need to
> release the BSC from the AUTO_I2C control.
>
> Cc: Kamal Dasu
> Cc: Florian Fai
On Mon, Feb 24, 2020 at 10:06:03AM +0100, Maxime Ripard wrote:
> Switch the DT binding to a YAML schema to enable the DT validation.
>
> Cc: Kamal Dasu
> Cc: Florian Fainelli
> Cc: Rob Herring
> Cc: Wolfram Sang
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: linux-
device with two register range,
> which will allow us to use or or the other in the driver without
> changing anything in the DT.
>
> Cc: Kamal Dasu
> Cc: Florian Fainelli
> Cc: Rob Herring
> Cc: Wolfram Sang
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: linux-...@
On Mon, Feb 24, 2020 at 10:06:03AM +0100, Maxime Ripard wrote:
> Switch the DT binding to a YAML schema to enable the DT validation.
>
> Cc: Kamal Dasu
> Cc: Florian Fainelli
> Cc: Rob Herring
> Cc: Wolfram Sang
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: linux-
On Wed, Feb 12, 2020 at 10:46:28AM +0100, Wolfram Sang wrote:
>
> The printout for txabrt is way too talkative. Reduce it to the minimum,
> the rest can be gained by I2C core debugging and datasheet information.
> Also, make it a debug printout, it won't help the regular user.
>
&
Hi,
> > Sorry, normally I don't do counter patches. Yet, this time I realized
> > that it would be faster to actually do what I envisioned than to
> > describe it in words. I hope you don't feel offended.
>
> No problem. I had thought a little about that myself, but did not
> dare to solve more
The printout for txabrt is way too talkative. Reduce it to the minimum,
the rest can be gained by I2C core debugging and datasheet information.
Also, make it a debug printout, it won't help the regular user.
Reported-by: H. Nikolaus Schaller
Signed-off-by: Wolfram Sang
---
Sorry, normally I
On Thu, Nov 07, 2019 at 09:33:54AM +0100, Daniel Vetter wrote:
> On Wed, Nov 06, 2019 at 10:50:23AM +0100, Wolfram Sang wrote:
> > Move from the deprecated i2c_new_probed_device() to the new
> > i2c_new_scanned_device(). Make use of the new ERRPTR if suitable.
> >
> >
On Wed, Nov 06, 2019 at 10:50:23AM +0100, Wolfram Sang wrote:
> Move from the deprecated i2c_new_probed_device() to the new
> i2c_new_scanned_device(). Make use of the new ERRPTR if suitable.
>
> Signed-off-by: Wolfram Sang
Applied to for-next, thanks!
signature.asc
Desc
From: Wolfram Sang
In the on-going mission to let i2c_new_* calls return an ERR_PTR instead
of NULL, here is a series converting i2c_new_probed_device(). A new
function called i2c_new_scanned_device() is introduced with the new
retval, but for now, a compatibility helper is provided until all
1 - 100 of 281 matches
Mail list logo
