> MAINTAINERS. It'll probably apply cleanly to 5.15-rc5 but if that happens
> again
It doesn't because Linus' git doesn't have:
Documentation/devicetree/bindings/pci/apple,pcie.yaml
Because MAINTAINER dependencies can be a bit nasty, I suggest I drop the
MAINTAINER additions for now and we add
> I still don't have access to any old PASemi hardware but the changes from
> v1 are pretty small and I expect them to still work. Would still be nice
> if someone with access to such hardware could give this a quick test.
Looks good to me. I will wait a few more days so that people can report
> F: arch/arm64/boot/dts/apple/
> +F: drivers/i2c/busses/i2c-pasemi-platform.c
We have no dedicated maintainer for PASEMI. Are maybe you or your
project interested in maintaining the pasemi-core, too? I guess not many
patches will show up and they will likely be for M1 anyhow.
If so, then
> I tried this but I still have xsane Version: 0.999-12 so there was no
> change. I couldn't find a newer version of xsane, even in Ubuntu.
> Indeed in the Ubuntu pool that I checked, the xsane directory was empty.
You need a newer version of libsane than debian testing. Probably
packages
> I tried this but I still have xsane Version: 0.999-12 so there was no
> change. I couldn't find a newer version of xsane, even in Ubuntu.
> Indeed in the Ubuntu pool that I checked, the xsane directory was empty.
You need a newer version of libsane than debian testing. Probably
packages
> I tried this but I still have xsane Version: 0.999-12 so there was no
> change. I couldn't find a newer version of xsane, even in Ubuntu.
> Indeed in the Ubuntu pool that I checked, the xsane directory was empty.
You need a newer version of libsane than debian testing. Probably
packages
Hi,
thank you for reporting and sorry for the issues the focus updates
caused you.
> Ant suggestions or help? How can I revert to a working version?
It is more like "update to a newer version".
Either you wait until Debian updates "testing" to the new 1.0.33 version
which is already in
> i2c-8 i2c PA Semi SMBus adapter at 0x(ptrval) I2C
> adapter
> i2c-9 i2c PA Semi SMBus adapter at 0x(ptrval) I2C
> adapter
> i2c-10i2c PA Semi SMBus adapter at 0x(ptrval)
> I2C adapter
As Sven correctly switched
> This looks all very good to me, I had one very minor comment.
>
> Whole series
>
> Reviewed-by: Arnd Bergmann
Thanks for the series and the review!
Same here, looks good to me and I only had one minor comment.
signature.asc
Description: PGP signature
> drivers/i2c/busses/i2c-pasemi-apple.c | 122 ++
Can't we name it 'i2c-pasemi-platform.c' instead? Makes more sense to me
because the other instance is named -pci.
signature.asc
Description: PGP signature
> Sure, will do that later as well!
But please do it privately. For upstreaming, the patch series you sent
is way better than a single patch.
signature.asc
Description: PGP signature
> Thanks Wolfram, please do !
Done. You're welcome.
signature.asc
Description: PGP signature
> Thanks. Compare works, but doesn't give me a "merge request" option :-(
I don't see why it is failing for you, but I fetched your branch and
pushed it to my gitlab fork. I see the option to create a merge request.
So, if all fails, I can create the merge request for you and apply it.
> Wolfgang has been managing milestones added to issues and MRs that are to be
Wolfram, please ;)
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
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
Hi,
> > - Creating a milestone on GitLab to assign all relevant issues/MRs to
>
> I am willing to do this.
I created now the 1.0.33 milestone and, so far, added closed issues (by
code changes) and merged requests since 1.0.32. I will add open tickets
later today.
This is the first time I do
> - Creating a milestone on GitLab to assign all relevant issues/MRs to
I am willing to do this.
signature.asc
Description: PGP signature
Lots of Epson scanners were added since the last release. Would be
really nice to push this out to users. So, yay!
signature.asc
Description: PGP signature
Hi all,
On Wed, Jul 14, 2021 at 10:38:31AM +0700, Quan Nguyen wrote:
> Slave needs time to prepare the response data before Master could
> enquiry via read transaction. However, there is no mechanism for
> i2c-aspeed Slave to notify Master that it needs more time to process
> and this make Master
> Acked-by: Benjamin Tissoires (For hid)
> Acked-by: Thorsten Scherer (For siox)
> Acked-by: Sven Van Asbroeck (For anybuss)
> Acked-by: Ulf Hansson (For MMC)
> Signed-off-by: Uwe Kleine-König
Acked-by: Wolfram Sang # for I2C
Thanks, Uwe!
signature.asc
Description: PGP signature
> Acked-by: Benjamin Tissoires (For hid)
> Acked-by: Thorsten Scherer (For siox)
> Acked-by: Sven Van Asbroeck (For anybuss)
> Acked-by: Ulf Hansson (For MMC)
> Signed-off-by: Uwe Kleine-König
Acked-by: Wolfram Sang # for I2C
Thanks, Uwe!
signature.asc
Description: PGP signature
> Acked-by: Benjamin Tissoires (For hid)
> Acked-by: Thorsten Scherer (For siox)
> Acked-by: Sven Van Asbroeck (For anybuss)
> Acked-by: Ulf Hansson (For MMC)
> Signed-off-by: Uwe Kleine-König
Acked-by: Wolfram Sang # for I2C
Thanks, Uwe!
signature.asc
Description: PGP signature
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
On Wed, May 19, 2021 at 02:49:28PM +0700, Quan Nguyen wrote:
> Expose the PEC calculation i2c_smbus_pec() for generic use.
>
> Signed-off-by: Quan Nguyen
You are the second one who wanted this exported. I agree it makes sense
for slave drivers. So, I'll skip the required user because two are in
The aforementioned patch is now upstream as commit:
63942f7a7473496d1160f02f5c1da3620525690d # gt68xx: fix use-after-free and two
mem leaks
Thanks for the report!
signature.asc
Description: PGP signature
On Tue, Jun 08, 2021 at 09:57:43PM +0200, Wolfram Sang wrote:
> Hi,
>
> I don't know how many developers also track pull requests on Gitlab. I
> have proposed one patch which affects 91 drivers, so I thought I
> advertise it here as well to collect reviews. It is this pull requ
> I understand that people sometimes have quite strong views on these things
> so I guess I'm putting it out there for comment.
No strong opinion here. Yet, all the channels and people I am interested
in moved to Libera in deed. I'd suggest to move with them. If not, well,
I will just connect to
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
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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
then.
Hope it helps!
From 63942f7a7473496d1160f02f5c1da3620525690d Mon Sep 17 00:00:00 2001
From: Wolfram Sang
Date: Thu, 10 Jun 2021 11:32:04 +0200
Subject: [PATCH] gt68xx: fix use-after-free and two mem leaks
The config file argument needs to be freed when a device is not set.
That was missed
I found the culprit (hiding between the confusing indentation). No need
to send more data. I will work now on a fix.
signature.asc
Description: PGP signature
Hi,
> > SANE_DEBUG_GT68XX=5 scanimage -L
Could you kindly also provide this output?
SANE_DEBUG_GT68XX=5 SANE_DEBUG_DLL=3 scanimage -L
Let's hope this will bring something new...
Kind regards,
Wolfram
signature.asc
Description: PGP signature
Hi,
I don't know how many developers also track pull requests on Gitlab. I
have proposed one patch which affects 91 drivers, so I thought I
advertise it here as well to collect reviews. It is this pull request:
https://gitlab.com/sane-project/backends/-/merge_requests/632
with this description:
> I folded the patch now into the upstream code base. I did some generic
> cleanups to USB ids before applying your slightly modified patch. You
> can find all this in the "epson2-new-usbids" branch of my repo:
>
> https://gitlab.com/wsakernel/backends/-/tree/epson2-new-usbids
Merged now. Thank
Hello Nakamura-san, all,
I folded the patch now into the upstream code base. I did some generic
cleanups to USB ids before applying your slightly modified patch. You
can find all this in the "epson2-new-usbids" branch of my repo:
https://gitlab.com/wsakernel/backends/-/tree/epson2-new-usbids
I
Hi Ashwin,
> My understanding of steps that I need to follow for adding a new hardware
> support to sigrok is as follows :
>
> *Step 1:* Use the new-driver script to generate skeleton files (api.c,
> protocol.c/.h)
> *Step 2: *Modify created files accordingly to support FX3.
> *Step 3:* I need
> 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
> 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
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
_
Hello Nakamura-san,
> About your question, we have implemented Zeroconf support to implement auto
> scanner discovery.
> However, this is only needed for "epsonds", because "epson2" already has this
> feature by the other logic.
> i.e. We have accidentally implemented this feature to "epson2"
Hello Nakamura-san,
> The main update from the previous release is as below : (Please refer the
> included "Release Note for Epson SANE driver update patch.pdf" also.)
> + Fix the upside down issue for back side image when scanning with
> duplex ADF setting for some models
> +
On Wed, May 26, 2021 at 11:02:45AM +1000, Michael Ellerman wrote:
> Wolfram Sang writes:
> > On Wed, May 12, 2021 at 09:20:48AM +1200, Chris Packham wrote:
> >> The P2040/P2041 has an erratum where the i2c recovery scheme
> >> documented in the reference manual
On Wed, May 12, 2021 at 09:20:48AM +1200, Chris Packham wrote:
> The P2040/P2041 has an erratum where the i2c recovery scheme
> documented in the reference manual (and currently implemented
> in the i2c-mpc.c driver) does not work. The errata document
> provides an alternative that does work. This
Hello Nakamura-san,
> During our internal review about "split into epson2 and epsonds", we
> found the issues of "epson2". So, we will fix the issues of "epson2",
> split the patch into epson2/epsonds and release again for your review.
I understand. I will happily wait for the new version then.
Hello Nakamura-san,
> We have applied many pieces of changes for one improvement and we have much
> difficulties to separate them to smaller patches
> which are free from dependencies among each patches.
Yes, it is very difficult afterwards if the patch has already been
created. Do you think
> > Yes and no. I am quite optimistic the bug was fixed with a patch which
> > is included upstream since 4.19-rc1. It still needs confirmation,
> > though, i.e. testing.
>
> The PowerMac G5 users on this list are kindly asked to confirm the bug has
> been fixed. Until then, I'll reopen it.
> > Yes and no. I am quite optimistic the bug was fixed with a patch which
> > is included upstream since 4.19-rc1. It still needs confirmation,
> > though, i.e. testing.
>
> The PowerMac G5 users on this list are kindly asked to confirm the bug has
> been fixed. Until then, I'll reopen it.
> > Yes and no. I am quite optimistic the bug was fixed with a patch which
> > is included upstream since 4.19-rc1. It still needs confirmation,
> > though, i.e. testing.
>
> The PowerMac G5 users on this list are kindly asked to confirm the bug has
> been fixed. Until then, I'll reopen it.
> Wolfram just said that the you don't need custom kernels anymore but he
> didn't say whether the original bug report that the windfarm modules didn't
> load was fixed, did he?
Yes and no. I am quite optimistic the bug was fixed with a patch which
is included upstream since 4.19-rc1. It still
> Any reporting back here?
For the record, no need to build custom kernels anymore. Any Debian
supplied kernel 4.19 or later will do for testing.
signature.asc
Description: PGP signature
> Any reporting back here?
For the record, no need to build custom kernels anymore. Any Debian
supplied kernel 4.19 or later will do for testing.
signature.asc
Description: PGP signature
> Any reporting back here?
For the record, no need to build custom kernels anymore. Any Debian
supplied kernel 4.19 or later will do for testing.
signature.asc
Description: PGP signature
included in the package.
> > Could you please verify the patch and investigate to apply to SANE
> > Project?
Thank you very much for your work at Epson so far!
> We have a new maintainer, Wolfram Sang for the epson2 backend and I
> believe that M. Allan Noah has been
Hi,
> sorry, I've been away for a while.
No worries, thanks for the log file.
> [07:57:42.570625] [gt68xx] sane_get_devices: exit
> [07:57:44.957116] [gt68xx] sane_exit: start
> [07:57:44.957176] [gt68xx] sane_exit: exit
> device `gt68xx:libusb:005:003' is a Plustek PI&�U flatbed scanner
This
On Sat, Apr 17, 2021 at 02:46:52PM +0800, Qii Wang wrote:
> The parameters of tSU,STA/tHD,STA/tSU,STOP maybe out of spec due
> to device clock-stretch or circuit loss, we could get a suitable
> scl_int_delay_ns from i2c_timings to compensate these parameters
> to meet the spec via EXT_CONF
On Sat, Apr 17, 2021 at 02:46:51PM +0800, Qii Wang wrote:
> The right flag is apdma_sync when apdma remove hand-shake signel.
>
> Signed-off-by: Qii Wang
Added:
Fixes: 05f6f7271a38 ("i2c: mediatek: Fix apdma and i2c hand-shake timeout")
and applied to for-next, thanks!
signature.asc
On Sat, Apr 17, 2021 at 02:46:50PM +0800, Qii Wang wrote:
> There are some omissions in the previous patch about replacing
> I2C_MAX_FAST_MODE__FREQ with I2C_MAX_FAST_MODE_PLUS_FREQ and
> need to fix it.
>
> Fixes: b44658e755b5("i2c: mediatek: Send i2c master code at more than 1MHz")
>
Linus,
here is one more driver bugfix for I2C.
Please pull.
Thanks,
Wolfram
The following changes since commit d434405aaab7d0ebc516b68a8fc4100922d7f5ef:
Linux 5.12-rc7 (2021-04-11 15:16:13 -0700)
are available in the Git repository at:
On Thu, Apr 15, 2021 at 11:38:02AM +0200, Krzysztof Kozlowski wrote:
> Use of_device_get_match_data() to make the code slightly smaller.
>
> Signed-off-by: Krzysztof Kozlowski
Applied to for-next, thanks!
signature.asc
Description: PGP signature
Hi Bence,
On Mon, Apr 12, 2021 at 11:53:02AM +, Bence Csókás wrote:
> While the preamble field _is_ technically big-endian, its value is always
> 0x2A2A,
> which is the same in either endianness, therefore it should be u16 instead.
Why should it be u16? I don't see it.
I thought the fix
On Thu, Apr 15, 2021 at 10:33:19AM +1200, Chris Packham wrote:
> I've tested on T2081 and P2041 based systems with a number of i2c and smbus
> devices.
>
> I've included some clean ups provided by Andy Shevchenko to make applying the
> series easier.
Applied to for-next, thanks!
signature.asc
On Thu, Apr 15, 2021 at 04:15:07PM +0800, Jie Deng wrote:
> On 2021/4/15 15:28, Wolfram Sang wrote:
>
> > > Now that we were able to catch you, I will use the opportunity to
> > > clarify the doubts I had.
> > >
> > > - struct mute
> Now that we were able to catch you, I will use the opportunity to
> clarify the doubts I had.
>
> - struct mutex lock in struct virtio_i2c, I don't think this is
> required since the core takes care of locking in absence of this.
This is likely correct.
> - Use of I2C_CLASS_DEPRECATED
> I didn't forget this. It is a very small change. I'm not sure if the
> maintainer Wolfram
>
> has any comments so that I can address them together in one version.
Noted. I'll have a look in the next days.
signature.asc
Description: PGP signature
> > > Platform data is a legacy interface to supply device properties
> > > to the driver. In this case we don't have anymore in-kernel users
> > > for it. Just remove it for good.
> > >
> > > Signed-off-by: Andy Shevchenko
> >
> >
On Thu, Apr 08, 2021 at 07:06:38PM +0800, Ye Weihua wrote:
> The PM reference count is not expected to be incremented on return in
> these functions.
>
> However, pm_runtime_get_sync() will increment the PM reference count
> even on failure. forgetting to put the reference again will result in
>
On Thu, Apr 08, 2021 at 08:56:48PM +0800, Li Huafei wrote:
> pm_runtime_get_sync will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here. Fix
> it by replacing it with pm_runtime_resume_and_get to keep usage counter
> balanced.
>
>
On Thu, Apr 08, 2021 at 08:59:15PM +0800, Li Huafei wrote:
> pm_runtime_get_sync will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here. Fix
> it by replacing it with pm_runtime_resume_and_get to keep usage counter
> balanced.
>
>
On Thu, Apr 08, 2021 at 07:29:10PM +0800, Pu Lehui wrote:
> pm_runtime_get_sync() will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get() to keep usage
> counter balanced.
>
>
On Thu, Apr 08, 2021 at 07:23:52PM +0800, Pu Lehui wrote:
> pm_runtime_get_sync() will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get() to keep usage
> counter balanced.
>
>
On Thu, Apr 08, 2021 at 07:19:30PM +0800, Ye Weihua wrote:
> The PM reference count is not expected to be incremented on return in
> ipi2c_imx_master_enable().
>
> However, pm_runtime_get_sync() will increment the PM reference count
> even on failure. forgetting to put the reference again will
On Wed, Apr 07, 2021 at 11:30:30AM +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() will increase the rumtime PM counter
> even it returns an error. Thus a pairing decrement is needed
> to prevent refcount leak. Fix this by replacing this API with
> pm_runtime_resume_and_get(), which will not
On Tue, Dec 01, 2020 at 05:29:24PM +0800, Qinglang Miao wrote:
> pm_runtime_get_sync will increment the PM reference count
> even failed. Forgetting to putting operation will result
> in a reference leak here.
>
> Replace it with pm_runtime_resume_and_get to keep usage
> counter balanced.
>
>
On Mon, Apr 12, 2021 at 08:03:14PM +0800, Qii Wang wrote:
> On Wed, 2021-04-07 at 20:19 +0200, Wolfram Sang wrote:
> > > Due to clock stretch, our HW IP cannot meet the ac-timing
> > > spec(tSU;STA,tSU;STO).
> > > There isn't a same delay for clock stretching, so
On Tue, Apr 13, 2021 at 05:48:21PM +0800, Yang Li wrote:
> Fix the following versioncheck warnings:
> ./drivers/i2c/busses/i2c-xgene-slimpro.c: 22 linux/version.h not needed.
> ./drivers/i2c/busses/i2c-brcmstb.c: 25 linux/version.h not needed.
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang
On Tue, Apr 13, 2021 at 05:09:56PM +1200, Chris Packham wrote:
> Add Chris Packham as FREESCALE MPC I2C maintainer.
>
> Signed-off-by: Chris Packham
Applied to for-next, thanks for stepping up, much appreciated!
signature.asc
Description: PGP signature
e last entry in mpc_i2c_dividers_8xxx. Checking for div being NULL
> after the loop is redundant so remove the check.
>
> Reported-by: Wolfram Sang
> Signed-off-by: Chris Packham
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Tue, Apr 13, 2021 at 05:09:53PM +1200, Chris Packham wrote:
> The fsl-i2c controller will generate an interrupt after every byte
> transferred. Make use of this interrupt to drive a state machine which
> allows the next part of a transfer to happen as soon as the interrupt is
> received. This
> Yongjun[1] into the original patch. If Wei's patch is applied on top
> of whats already in i2c/for-next then this patch can be ignored.
I applied Wei's patch instead. It was easier.
signature.asc
Description: PGP signature
Hi Chris,
> Yep I plan on being around. I've got access to a couple of designs with
> P2040 and T2081 so hopefully that's sufficient to deal with any
> regressions. One issue is a lack of different i2c devices (the systems
> we have tend to use the same devices) but hopefully any reports of
>
On Mon, Mar 29, 2021 at 02:52:04PM +1300, Chris Packham wrote:
> All the in-tree dts files that use one of the compatible strings from
> i2c-mpc.c provide an interrupt property. By making this mandatory we
> can simplify the code.
>
> Signed-off-by: Chris Packham
After I applied this patch,
On Mon, Mar 29, 2021 at 02:52:06PM +1300, Chris Packham wrote:
> The fsl-i2c controller will generate an interrupt after every byte
> transferred. Make use of this interrupt to drive a state machine which
> allows the next part of a transfer to happen as soon as the interrupt is
> received. This
On Sun, Mar 21, 2021 at 06:38:32PM -0700, Dmitry Torokhov wrote:
> More and more drivers rely on devres to manage their resources, however
> if bus' probe() and release() methods are not trivial and control some
> of resources as well (for example enable or disable clocks, or attach
> device to a
On Mon, Mar 29, 2021 at 01:50:35PM +0300, Heikki Krogerus wrote:
> Hi,
>
> The old device property API (device_add_properties()) is going to be
> removed. These prepare the i2c subsystem and drivers for the change.
> The change is fairly trivial in case of i2c. All we need to do is add
> complete
Shevchenko (1):
i2c: designware: Adjust bus_freq_hz when refuse high speed mode set
Bhaskar Chowdhury (1):
i2c: stm32f4: Mundane typo fix
Hao Fang (1):
i2c: hix5hd2: use the correct HiSilicon copyright
Krzysztof Kozlowski (1):
i2c: exynos5: correct top kerneldoc
Wolfram Sang (4
> Can we add this later if needed?
> Because in such case additionally printing bus_freq_hz will be fine, no?
Yes, we can do that.
> But putting max to each frequency representation in the list of strings sounds
> good to me.
It is not important to me if we are going to change that later
The following commit has been merged into the timers/core branch of tip:
Commit-ID: fe8324f37cfebf72e2669e97b9d76ea9794d2972
Gitweb:
https://git.kernel.org/tip/fe8324f37cfebf72e2669e97b9d76ea9794d2972
Author:Wolfram Sang
AuthorDate:Thu, 11 Mar 2021 10:09:18 +01:00
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 68c70aae06e9660473a00fd7d68e0b53f4d7b6f4
Gitweb:
https://git.kernel.org/tip/68c70aae06e9660473a00fd7d68e0b53f4d7b6f4
Author:Wolfram Sang
AuthorDate:Tue, 09 Mar 2021 10:44:48 +01:00
On Mon, Mar 29, 2021 at 01:50:35PM +0300, Heikki Krogerus wrote:
> Hi,
>
> The old device property API (device_add_properties()) is going to be
> removed. These prepare the i2c subsystem and drivers for the change.
> The change is fairly trivial in case of i2c. All we need to do is add
> complete
On Tue, Mar 30, 2021 at 03:58:56PM +0200, Max Staudt wrote:
> This looks great, thank you for constifying this.
>
> Finally it's clean again, yet much more flexible than the original
> platform_data approach when I first submitted the driver.
I read this as "Reviewed-by" ;)
signature.asc
On Thu, Apr 08, 2021 at 07:17:20PM +0800, Yicong Yang wrote:
> Add maintainer for HiSilicon I2C driver.
Only if you need to resend, then you can squash this into the previous
patch. If not, I can do it when applying.
signature.asc
Description: PGP signature
> +const char *i2c_freq_mode_string(u32 bus_freq_hz)
> +{
> + switch (bus_freq_hz) {
> + case I2C_MAX_STANDARD_MODE_FREQ:
> + return "Standard Mode (100 kHz)";
Sorry, I just noticed just now. Shouldn't we also support lower
frequencies than the maximum one? I.e.
if
> Reason for temp variable is for me it's confusing to see statement like
> "rate_khz = rate_khz / 1000".
Yes. And with this clearer calculation, we can maybe skip the HZ_PER_KHZ
define completely and just use plain '1000' as a factor/divider because
it then becomes obvious. I still find the
> > I guess exporting will save few dozens of bytes if the function is used more
> > than once. (All strings will be duplicated or multiplied in that case)
> >
>
> yes, that's one concern. since we don't need this to perform fast, an inline
> one maybe unnecessary.
Exactly. I also don't see an
Hi, can you run this command please and provide the output?
SANE_DEBUG_GT68XX=5 scanimage -L
And can you test patches?
Regards, Wolfram
signature.asc
Description: PGP signature
201 - 300 of 16180 matches
Mail list logo
