Re: [PATCH v1 1/1] treewide: Align match_string() with sysfs_match_string()

2024-06-04 Thread Wolfram Sang
vchenko Acked-by: Wolfram Sang # for I2C signature.asc Description: PGP signature

Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers

2024-04-07 Thread Wolfram Sang
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 > >

Re: [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers

2024-04-05 Thread Wolfram Sang
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 >

Re: [PATCH v5 00/20] remove I2C_CLASS_DDC support

2023-12-19 Thread Wolfram Sang
> 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

Re: [Intel-gfx] [PATCH v5 00/20] remove I2C_CLASS_DDC support

2023-11-23 Thread Wolfram Sang
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

Re: [Intel-gfx] [PATCH 00/20] remove I2C_CLASS_DDC support

2023-11-13 Thread Wolfram Sang
> 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 differen

Re: [Intel-gfx] [PATCH 00/20] remove I2C_CLASS_DDC support

2023-11-13 Thread Wolfram Sang
> 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 signa

[Intel-gfx] [PATCH] gpu: move from strlcpy with unused retval to strscpy

2022-08-19 Thread 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: Wo

Re: [Intel-gfx] linux-next: build failure after merge of the i2c tree

2021-06-01 Thread Wolfram Sang
> Hi, this issue is fixed in > https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-gt-next&id=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

Re: [Intel-gfx] linux-next: build failure after merge of the i2c tree

2021-06-01 Thread Wolfram Sang
[PATCH] drm/i915/selftests: Avoid 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 signatu

Re: [Intel-gfx] [trivial PATCH] treewide: Convert switch/case fallthrough; to break;

2020-09-10 Thread Wolfram Sang
> 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) >

Re: [Intel-gfx] [PATCH] docs: fix some broken references due to txt->rst renames

2019-06-18 Thread Wolfram Sang
On Tue, Jun 18, 2019 at 10:33:58AM -0300, Mauro Carvalho Chehab wrote: > There are three left-overs from the recent file renames, > probably due to some other conflicting patch. > > Fix them. > > Signed-off-by: Mauro Carvalho Chehab Thanks! Acked-by: Wolfram Sang signatu

Re: [Intel-gfx] [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder

2017-08-17 Thread Wolfram Sang
> > > Signed-off-by: Lyude > > > > No full name? Or is it your full name? > Looks like I forgot to change my desktop's S-B identity to full name, > but it shouldn't be a big deal. I've got tons of other patches already > upstream like this. I'd much prefer a full name. But more importantly, wha

Re: [Intel-gfx] [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder

2017-08-12 Thread Wolfram Sang
to workaround this and not break either SMBus or > i915, we temporarily unmap the PCI device for the SMBus controller, > do the thing that the firmware wanted to do, then remap the device and > report a firmware bug. > > Signed-off-by: Lyude No full name? Or is it your full na

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for i2c: refactor core and break out blocks

2017-05-27 Thread Wolfram Sang
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4827/ As far as I can read the above page, all non-green blocks are caused by non-I2C issues. So, I'd assume my patch set doesn't break things. Good! signature.asc Description: PGP signature __

[Intel-gfx] [RFT 1/8] i2c: rename core source file to allow refactorization

2017-05-27 Thread Wolfram Sang
The I2C core became quite huge and its monolithic structure makes maintenance hard. So, prepare to break out some functionality into seperate files by renaming the source file. Note that we keep the resulting object name constant to avoid regressions. Signed-off-by: Wolfram Sang

[Intel-gfx] [RFT 6/8] docs: i2c: dev-interface: adapt to new filenames of the i2c core

2017-05-27 Thread Wolfram Sang
The I2C core files were renamed, adapt the textfile to it. Signed-off-by: Wolfram Sang --- Documentation/i2c/dev-interface | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface index bcf919d8625ceb

[Intel-gfx] [RFT 5/8] i2c: break out ACPI support into seperate file

2017-05-27 Thread Wolfram Sang
Removes some ifdeffery. Also add the new file to the relevant MAINTAINERS section. Signed-off-by: Wolfram Sang --- MAINTAINERS | 1 + drivers/i2c/Makefile| 1 + drivers/i2c/i2c-core-acpi.c | 653 drivers/i2c/i2c-core

[Intel-gfx] [RFT 3/8] i2c: break out smbus support into seperate file

2017-05-27 Thread Wolfram Sang
Break out the exported SMBus functions and the emulation layer into a seperate file. This also involved splitting up the tracing header into an I2C and an SMBus part. Signed-off-by: Wolfram Sang --- Documentation/driver-api/i2c.rst | 3 + drivers/i2c/Makefile | 2 +- drivers/i2c

[Intel-gfx] [RFT 7/8] i2c: remove unneeded includes from core

2017-05-27 Thread Wolfram Sang
They seem like cruft to me. I couldn't find any evidence that something included from there is actually used. Signed-off-by: Wolfram Sang --- drivers/i2c/i2c-core-base.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c

[Intel-gfx] [RFT 4/8] i2c: break out OF support into seperate file

2017-05-27 Thread Wolfram Sang
Also removes some ifdeffery. Signed-off-by: Wolfram Sang --- drivers/i2c/Makefile| 1 + drivers/i2c/i2c-core-base.c | 265 +- drivers/i2c/i2c-core-of.c | 276 drivers/i2c/i2c-core.h | 8 ++ 4

[Intel-gfx] [RFT 2/8] i2c: break out slave support into seperate file

2017-05-27 Thread Wolfram Sang
Also removes some ifdeffery. Signed-off-by: Wolfram Sang --- drivers/i2c/Makefile | 1 + drivers/i2c/i2c-core-base.c | 102 +- drivers/i2c/i2c-core-slave.c | 115 +++ drivers/i2c/i2c-core.h | 1 + 4

[Intel-gfx] [RFT 8/8] i2c: reformat core-base file header

2017-05-27 Thread Wolfram Sang
guys are fully credited in the i2c-mux file and b) add my own copyright for the period of me being the maintainer. Signed-off-by: Wolfram Sang --- drivers/i2c/i2c-core-base.c | 40 +++- 1 file changed, 19 insertions(+), 21 deletions(-) diff --git a/drivers/i2c

[Intel-gfx] [RFT 0/8] i2c: refactor core and break out blocks

2017-05-27 Thread Wolfram Sang
o not block other core changes. Let's see if we are there yet and the series is ready. Looking forward to comments. A branch can be found here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/core-refactor === Kind regards, Wolfram [1] https://lkml.org/lkml/2017/5/26/90

Re: [Intel-gfx] [PATCH 0/8] i2c: refactor core and break out blocks

2017-05-27 Thread Wolfram Sang
> If you don't mind sending the whole series to the intel-gfx list (Cc'd), > our CI will run a bunch of tests on it, exercising our use of the I2C > adapter interfaces for display data channel and I2C over Display Port > native aux. Cool, that sounds very helpful! Thanks for the offer, I'll resen

Re: [Intel-gfx] [PATCH 1/2] i2c: designware: Never suspend i2c-busses used for accessing the system PMIC

2017-02-27 Thread Wolfram Sang
On Mon, Feb 27, 2017 at 11:25:01AM +0100, Takashi Iwai wrote: > On Mon, 27 Feb 2017 10:38:29 +0100, > Hans de Goede wrote: > > > > index a8e74ca..a4ac473 100644 > > --- a/drivers/i2c/busses/i2c-designware-core.h > > +++ b/drivers/i2c/busses/i2c-designware-core.h > > @@ -79,7 +79,7 @@ > > * @pm_q

Re: [Intel-gfx] [PATCH v2 00/13] coordinate cht i2c-pmic and i915-punit accesses

2017-01-25 Thread Wolfram Sang
> So the plan (again with Wolfram's ack) is for all these patches > including the i2c-designware ones to go upstream through the drm-intel > tree, to avoid an intermediate state were things don't work. Yes. I'd just like to pull in an immutable branch into my i2c/for-next once this series is acce

Re: [Intel-gfx] [PATCH v5 1/6] i2c: designware: Rename accessor_flags to flags

2017-01-15 Thread Wolfram Sang
Reviewed-by: Andy Shevchenko > Acked-by: Jarkko Nikula > Tested-by: Takashi Iwai This and the whole series is: Acked-by: Wolfram Sang signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https

Re: [Intel-gfx] [PATCH 3/7] i2c: designware-baytrail: Take punit lock on bus acquire

2017-01-15 Thread Wolfram Sang
> Once I've a patch-set everyone likes I will start talking to people > to coordinate the merging, I believe it is probably best for all this > to be merged through the drm-intel tree. But we'll see about that > when the patch-set is ready. Agreed. signature.asc Description: PGP signature

Re: [Intel-gfx] [PATCH 3/7] i2c: designware-baytrail: Take punit lock on bus acquire

2017-01-15 Thread Wolfram Sang
Hi Hans, > So Wolfram, what is the plan with these ? As said they are necessary > for the 2 i2c patches in this patch-set, so do you want the > entire set of 8 i2c patches to go through an other tree to avoid > inter tree dependencies ? Thanks for the heads up. So, my plan was that I send a pull

Re: [Intel-gfx] [PATCH 3/7] i2c: designware-baytrail: Take punit lock on bus acquire

2017-01-12 Thread Wolfram Sang
; bus, which results in a hang when it happens while we own the pmic i2c > bus semaphore. > > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 > Signed-off-by: Hans de Goede > Tested-by: tagorereddy I don't think the I2C patches need to go via I2C t

Re: [Intel-gfx] [PATCH 4/7] i2c: designware-baytrail: Call pmic_bus_access_notifier_chain

2017-01-12 Thread Wolfram Sang
On Sun, Jan 08, 2017 at 02:44:24PM +0100, Hans de Goede wrote: > Call the iosf_mbi pmic_bus_access_notifier_chain on bus acquire / release. > > BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 > Signed-off-by: Hans de Goede > Tested-by: tagorereddy Acked-b

Re: [Intel-gfx] [PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

2014-09-25 Thread Wolfram Sang
On Thu, Sep 25, 2014 at 09:22:01AM -0500, Felipe Balbi wrote: > On Thu, Sep 25, 2014 at 01:27:18PM +0530, Vinod Koul wrote: > > On Wed, Sep 24, 2014 at 03:32:19PM -0500, Felipe Balbi wrote: > > > > > > OK, I guess this is as good as it gets. > > > > > > > > > > > > What tree would you like it go t