[PATCH 0/2]

[PATCH 0/2]

[Pablo Neira Ayuso]

Hi Patrick,

The first patch here re-works the conntrack event cache to use the
extension infrastructure so there is an event cache per-conntrack.
This is used by the second patch, which aims to improve ctnetlink
reliability.

Please, have a look at the patch descriptions for more details.
If you like them, you can pull them from:

git://1984.lsi.us.es/nf-next-2.6 master

Wait for your comments!

---

Pablo Neira Ayuso (2):
      netfilter: conntrack: optional reliable conntrack event delivery
      netfilter: conntrack: move event cache to conntrack extension infrastructure


 include/net/netfilter/nf_conntrack.h        |    2 
 include/net/netfilter/nf_conntrack_ecache.h |  133 +++++++++--------
 include/net/netfilter/nf_conntrack_extend.h |    2 
 include/net/netfilter/nf_conntrack_helper.h |    2 
 include/net/netns/conntrack.h               |    7 +
 net/netfilter/nf_conntrack_core.c           |  106 ++++++++++---
 net/netfilter/nf_conntrack_ecache.c         |  216 ++++++++++++++++++---------
 net/netfilter/nf_conntrack_helper.c         |   15 ++
 net/netfilter/nf_conntrack_netlink.c        |   94 +++++++-----
 9 files changed, 379 insertions(+), 198 deletions(-)

[PATCH 0/2]

[dmitry pervushin]

Hello all,

These patches update idletimer extension to reflect changes in the kernel

[PATCH 1/2] netfilter: idletimers, synchronize headers
[PATCH 2/2] netfilter: idletimers, add v1 structures

[PATCH 0/2]

[Dolev Raviv]

Those patches replace the previous Query Request and NOP patches:
[PATCH 1/8] scsi: ufs: add support for query
[PATCH 7/8] scsi: ufs: Set fDeviceInit flag to initiate device initialization
[PATCH 8/8] scsi: ufs: Fix the response UPIU length setting

And depends on:
[PATCH 2/8] scsi: ufs: wrap the i/o access operations
[PATCH 3/8] scsi: ufs: amend interrupt configuration
[PATCH 4/8] scsi: ufs: remove version check before IS reg clear
[PATCH 5/8] scsi: ufs: rework link start-up process

Sending the query request via the SCSI vendor specific command can cause a deadlock
in case the SCSI command queue is blocked and we would like to send a query request 
(for example fDeviceInit in case of re-initialization).
In addition, usage of a vendor specific SCSI command for UFS can cause future conflicts
if this vendor specific command will be allocated for a different usage.

The below patches allocate an internal tag for NOP and query requests and do not
involve the SCSI layer in UFS specific requests transfers. 
This design also resolves the possible deadlock mentioned above.


Dolev Raviv (1):
  scsi: ufs: Set fDeviceInit flag to initiate device initialization

Sujit Reddy Thumma (1):
  scsi: ufs: Add support for sending NOP OUT UPIU

 drivers/scsi/ufs/ufs.h    |  127 +++++++-
 drivers/scsi/ufs/ufshcd.c |  802 ++++++++++++++++++++++++++++++++++++++------
 drivers/scsi/ufs/ufshcd.h |   40 +++-
 drivers/scsi/ufs/ufshci.h |    2 +-
 4 files changed, 849 insertions(+), 122 deletions(-)

-- 
1.7.6
-- 
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH 0/2]

[alison_chaiken at mentor.com]

From: Alison Chaiken <alison_chaiken@mentor.com>

Tested on a variety of i.MX6 reference boards with older kernels.    Newly added
pinctrl configuration settings that are not tested are not modified.

Changes since v1:
 * Now rebased on linux-next.

Alison Chaiken (2):
  ARM: i.MX6: dts: change iomuxc pinctrl config to match Rev. 1 IMX6DQRM
  i.MX6: Documentation: Change fsl,imx-pinctrl.txt to match i.MX6 TRM

 .../bindings/pinctrl/fsl,imx-pinctrl.txt           |  25 +-
 arch/arm/boot/dts/imx6qdl.dtsi                     | 354 ++++++++++-----------
 arch/arm/boot/dts/imx6sl.dtsi                      |  48 +--
 3 files changed, 214 insertions(+), 213 deletions(-)

-- 
1.8.4

[PATCH 0/2]

[alison_chaiken]

From: Alison Chaiken <alison_chaiken@mentor.com>

Tested on a variety of i.MX6 reference boards with older kernels.    Newly added
pinctrl configuration settings that are not tested are not modified.

Changes since v1:
 * Now rebased on linux-next.

Alison Chaiken (2):
  ARM: i.MX6: dts: change iomuxc pinctrl config to match Rev. 1 IMX6DQRM
  i.MX6: Documentation: Change fsl,imx-pinctrl.txt to match i.MX6 TRM

 .../bindings/pinctrl/fsl,imx-pinctrl.txt           |  25 +-
 arch/arm/boot/dts/imx6qdl.dtsi                     | 354 ++++++++++-----------
 arch/arm/boot/dts/imx6sl.dtsi                      |  48 +--
 3 files changed, 214 insertions(+), 213 deletions(-)

-- 
1.8.4

[PATCH 0/2]

[Vadim Suraev]

rte_timer: 2 bug fixes

Vadim Suraev (2):
  rte_timer bug fix: pending timers count is not  decremented when
    going running. Fix: decrement pending when going running, increment
    if reloaded, do nothing if not reloaded     Signed-off-by: Vadim
    Suraev <vadim.suraev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  rte_timer bug fix: when a perdiodic timer's callback manipulates
    another timer, updated flag prevents reloading the periodic timer.
    Fix: move  updated flag to rte_timer structure (one per core)    
    Signed-off-by: Vadim Suraev <vadim.suraev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

 lib/librte_timer/rte_timer.c |   21 ++++++++++-----------
 lib/librte_timer/rte_timer.h |    7 ++++++-
 2 files changed, 16 insertions(+), 12 deletions(-)

-- 
1.7.9.5

Re: [PATCH 0/2]

[Thomas Monjalon]

Hi Vadim,

Your new patchset trial is better but not correct:
- all is in the title.
- the title must be short and begin with "timer:" as it's done for previous 
timer patches
- you must describe the bug you are fixing

I think you'll understand the problem by looking at the archives:
http://dpdk.org/ml/archives/dev/2014-May/002466.html

Please try again
-- 
Thomas

[PATCH 0/2]

[Vadim Suraev]

two timer bugs fixed

 lib/librte_timer/rte_timer.c |   21 ++++++++++-----------
 lib/librte_timer/rte_timer.h |    7 ++++++-
 2 files changed, 16 insertions(+), 12 deletions(-)

-- 
1.7.9.5

[PATCH 0/2]

[Jim Qu]

Jim Qu (2):
  drm/amd/amdgpu: fix console deadlock if late init failed
  drm/amd/amdgpu: add atomic helper to suspend/resume functions

 drivers/gpu/drm/amd/amdgpu/amdgpu.h        |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 182 +++++++++++++++++------------
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c     |   7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |   2 +-
 4 files changed, 115 insertions(+), 77 deletions(-)

-- 
1.9.1

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 0/2]

[Benjamin Gaignard]

Those patches aim to complete stm32 timer features support.
The last missing part is to be able to chain to timer blocks
which mean that one of timerX's trigger could be used as clock for timerY.

Since this operating is neither event or buffer triggered mode I would
like to introduce a hardware triggered mode in IIO core.

Benjamin Gaignard (2):
  iio: add hardware triggered operating mode
  iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode

 .../ABI/testing/sysfs-bus-iio-timer-stm32          | 15 ++++++
 drivers/iio/industrialio-core.c                    |  4 +-
 drivers/iio/trigger/stm32-timer-trigger.c          | 61 ++++++++++++++++++++++
 include/linux/iio/iio.h                            |  6 +++
 4 files changed, 84 insertions(+), 2 deletions(-)

-- 
1.9.1

[PATCH 0/2]

[Amanda Brindle]

The following changes since commit b73e96e7f3f5d1ba3a221d99792a7a3c7ef42c21:

  python-scons: upgrade to v3.0.1; use pypi.bbclass (2017-12-13 14:00:52 +0000)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib abrindle/rprovides
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=abrindle/rprovides

Amanda Brindle (2):
  oe-pkgdata-util: Refactor functions for consistency
  oe-pkgdata-util: Add support for RPROVIDES

 scripts/oe-pkgdata-util | 173 +++++++++++++++++++++++++++---------------------
 1 file changed, 97 insertions(+), 76 deletions(-)

-- 
2.7.4

Re: [PATCH 0/2]

[Richard Purdie]

On Mon, 2017-12-18 at 14:12 -0800, Amanda Brindle wrote:
> The following changes since commit
> b73e96e7f3f5d1ba3a221d99792a7a3c7ef42c21:
> 
>   python-scons: upgrade to v3.0.1; use pypi.bbclass (2017-12-13
> 14:00:52 +0000)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib abrindle/rprovides
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=abrindle/r
> provides
> 
> Amanda Brindle (2):
>   oe-pkgdata-util: Refactor functions for consistency
>   oe-pkgdata-util: Add support for RPROVIDES
> 
>  scripts/oe-pkgdata-util | 173 +++++++++++++++++++++++++++-----------
> ----------
>  1 file changed, 97 insertions(+), 76 deletions(-)

Hi Amanda,

I pulled these into master-next for testing but we saw:

https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/753/steps/Running%20oe-selftest/logs/stdio

You can reproduce with:

oe-selftest -r pkgdata.OePkgdataUtilTests

Cheers,

Richard

[PATCH 0/2]

[Antoniu Miclaus]

The ADMV1013 is a wideband, microwave upconverter optimized
for point to point microwave radio designs operating in the
24 GHz to 44 GHz radio frequency (RF) range.

Datasheet:
https://www.analog.com/media/en/technical-documentation/data-sheets/ADMV1013.pdf

NOTE:
Currently depends on 64-bit architecture since the input
clock that server as Local Oscillator should support values
in the range 5.4 GHz to 10.25 GHz.

We might need some scaling implementation in the clock
framework so that u64 types are supported when using 32-bit
architectures.

Antoniu Miclaus (2):
  iio: frequency: admv1013: add support for ADMV1013
  dt-bindings: iio: frequency: add admv1013 doc

 .../bindings/iio/frequency/adi,admv1013.yaml  | 110 ++++
 drivers/iio/frequency/Kconfig                 |  13 +
 drivers/iio/frequency/Makefile                |   1 +
 drivers/iio/frequency/admv1013.c              | 579 ++++++++++++++++++
 4 files changed, 703 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml
 create mode 100644 drivers/iio/frequency/admv1013.c

-- 
2.33.1

[PATCH 0/2]

[Zhenneng Li]

For adapting radeon rx6600 xt on arm64 platform,
there report some compile errors.

Zhenneng Li (2):
  drm/amdgpu: fix compile error for dcn on arm64
  drm/amdgpu: enable dcn support on arm64

 drivers/gpu/drm/amd/display/Kconfig           |  2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
 .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
 .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
 drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
 13 files changed, 88 insertions(+), 1 deletion(-)

-- 
2.25.1


No virus found
		Checked by Hillstone Network AntiVirus

[PATCH 0/2]

[Zhenneng Li]

For adapting radeon rx6600 xt on arm64 platform,
there report some compile errors.

Zhenneng Li (2):
  drm/amdgpu: fix compile error for dcn on arm64
  drm/amdgpu: enable dcn support on arm64

 drivers/gpu/drm/amd/display/Kconfig           |  2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
 .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
 .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
 drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
 13 files changed, 88 insertions(+), 1 deletion(-)

-- 
2.25.1


No virus found
		Checked by Hillstone Network AntiVirus

[PATCH 0/2]

[Zhenneng Li]

For adapting radeon rx6600 xt on arm64 platform,
there report some compile errors.

Zhenneng Li (2):
  drm/amdgpu: fix compile error for dcn on arm64
  drm/amdgpu: enable dcn support on arm64

 drivers/gpu/drm/amd/display/Kconfig           |  2 +-
 drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
 .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
 drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
 .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
 .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
 drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
 drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
 drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
 13 files changed, 88 insertions(+), 1 deletion(-)

-- 
2.25.1


No virus found
		Checked by Hillstone Network AntiVirus

Re: [PATCH 0/2]

[Rodrigo Siqueira Jordao]

Hi Zhenneng,

+ some display folks

First of all, thanks a lot for your patch.

We had a similar patch in the past, but we had to revert it because we 
cannot simply enable DCN for ARM-based systems. You can refer to this 
commit message to get a better context:

https://gitlab.freedesktop.org/agd5f/linux/-/commit/c241ed2f0ea549c18cff62a3708b43846b84dae3

Before enabling ARM, we first need to isolate all FPU code in the DML 
folder fully. You can read more about our strategy at the below link:

https://patchwork.freedesktop.org/series/93042/

And you can see some examples of this effort in the below links:

- https://patchwork.freedesktop.org/series/95504/
- https://patchwork.freedesktop.org/patch/455465/?series=94441&rev=3
- https://patchwork.freedesktop.org/series/98247/

Soon we will submit another series that isolate DCN302, but we still 
need to isolate code from DCN20, DCN10, DCN303, and DCN301.

If you want to help us speed up this process, feel free to look at 
DCN301 or DCN10.

Best Regards
Siqueira

On 2022-01-07 4:57 a.m., Zhenneng Li wrote:
> For adapting radeon rx6600 xt on arm64 platform,
> there report some compile errors.
> 
> Zhenneng Li (2):
>    drm/amdgpu: fix compile error for dcn on arm64
>    drm/amdgpu: enable dcn support on arm64
> 
>   drivers/gpu/drm/amd/display/Kconfig           |  2 +-
>   drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
>   drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
>   .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
>   drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
>   13 files changed, 88 insertions(+), 1 deletion(-)
> 

Re: [PATCH 0/2]

[Rodrigo Siqueira Jordao]

Hi Zhenneng,

+ some display folks

First of all, thanks a lot for your patch.

We had a similar patch in the past, but we had to revert it because we 
cannot simply enable DCN for ARM-based systems. You can refer to this 
commit message to get a better context:

https://gitlab.freedesktop.org/agd5f/linux/-/commit/c241ed2f0ea549c18cff62a3708b43846b84dae3

Before enabling ARM, we first need to isolate all FPU code in the DML 
folder fully. You can read more about our strategy at the below link:

https://patchwork.freedesktop.org/series/93042/

And you can see some examples of this effort in the below links:

- https://patchwork.freedesktop.org/series/95504/
- https://patchwork.freedesktop.org/patch/455465/?series=94441&rev=3
- https://patchwork.freedesktop.org/series/98247/

Soon we will submit another series that isolate DCN302, but we still 
need to isolate code from DCN20, DCN10, DCN303, and DCN301.

If you want to help us speed up this process, feel free to look at 
DCN301 or DCN10.

Best Regards
Siqueira

On 2022-01-07 4:57 a.m., Zhenneng Li wrote:
> For adapting radeon rx6600 xt on arm64 platform,
> there report some compile errors.
> 
> Zhenneng Li (2):
>    drm/amdgpu: fix compile error for dcn on arm64
>    drm/amdgpu: enable dcn support on arm64
> 
>   drivers/gpu/drm/amd/display/Kconfig           |  2 +-
>   drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
>   drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
>   .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
>   drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
>   13 files changed, 88 insertions(+), 1 deletion(-)
> 

Re: [PATCH 0/2]

[Rodrigo Siqueira Jordao]

Hi Zhenneng,

+ some display folks

First of all, thanks a lot for your patch.

We had a similar patch in the past, but we had to revert it because we 
cannot simply enable DCN for ARM-based systems. You can refer to this 
commit message to get a better context:

https://gitlab.freedesktop.org/agd5f/linux/-/commit/c241ed2f0ea549c18cff62a3708b43846b84dae3

Before enabling ARM, we first need to isolate all FPU code in the DML 
folder fully. You can read more about our strategy at the below link:

https://patchwork.freedesktop.org/series/93042/

And you can see some examples of this effort in the below links:

- https://patchwork.freedesktop.org/series/95504/
- https://patchwork.freedesktop.org/patch/455465/?series=94441&rev=3
- https://patchwork.freedesktop.org/series/98247/

Soon we will submit another series that isolate DCN302, but we still 
need to isolate code from DCN20, DCN10, DCN303, and DCN301.

If you want to help us speed up this process, feel free to look at 
DCN301 or DCN10.

Best Regards
Siqueira

On 2022-01-07 4:57 a.m., Zhenneng Li wrote:
> For adapting radeon rx6600 xt on arm64 platform,
> there report some compile errors.
> 
> Zhenneng Li (2):
>    drm/amdgpu: fix compile error for dcn on arm64
>    drm/amdgpu: enable dcn support on arm64
> 
>   drivers/gpu/drm/amd/display/Kconfig           |  2 +-
>   drivers/gpu/drm/amd/display/dc/calcs/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/clk_mgr/Makefile   |  7 ++++++
>   drivers/gpu/drm/amd/display/dc/dcn10/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn20/Makefile |  4 +++
>   .../gpu/drm/amd/display/dc/dcn201/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn21/Makefile |  4 +++
>   drivers/gpu/drm/amd/display/dc/dcn30/Makefile |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn302/Makefile    |  6 +++++
>   .../gpu/drm/amd/display/dc/dcn303/Makefile    |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dcn31/Makefile |  6 +++++
>   drivers/gpu/drm/amd/display/dc/dml/Makefile   | 25 +++++++++++++++++++
>   drivers/gpu/drm/amd/display/dc/dsc/Makefile   |  7 ++++++
>   13 files changed, 88 insertions(+), 1 deletion(-)
> 

[PATCH 0/2]

[Laurent Pinchart]

Hello,

This small patch series simplifies colorspace handling for drivers by
sanitizing values in the V4L2 core.

Patch 1/2 improves the colorspace validity checks in existing helper
functions, to make them more future-proof. It's not a hard dependency
for the next patch, and could be dropped if desired.

Patch 2/2 then extends the v4l_sanitize_format() function to also
sanitize colorspace fields.

Laurent Pinchart (2):
  media: v4l2: Make colorspace validity checks more future-proof
  media: v4l2: Sanitize colorspace values in the framework

 drivers/media/v4l2-core/v4l2-ioctl.c | 65 +++++++++++++++++++++++-----
 include/media/v4l2-common.h          | 10 ++---
 include/uapi/linux/videodev2.h       | 29 +++++++++++++
 3 files changed, 89 insertions(+), 15 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH 0/2]

[Thinh Nguyen]

Fix reported issues where usb_request->no_interrupt is set for isoc
transfers.

* Make sure no interrupt is asserted if no_interrupt is set
* Make sure to stop reclaiming TRBs when the driver needs to stop

Just one of the fixes above may resolve the crash reported by Jeff and
Dan, but it's more proper to have both in place.


Thinh Nguyen (2):
  usb: dwc3: gadget: Stop processing more requests on IMI
  usb: dwc3: gadget: Don't set IMI for no_interrupt

 drivers/usb/dwc3/gadget.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)


base-commit: fb8f60dd1b67520e0e0d7978ef17d015690acfc1
-- 
2.28.0

[PATCH 0/2]

[Pranav Prasad]

This patch series adds fatal error checks for pm8001 driver
functions pm8001_phy_control() and pm8001_lu_reset().

1. Added a fatal error check in pm8001_phy_control().

2. Added a fatal error check in pm8001_lu_reset().

Changyuan Lyu (1):
  scsi: pm80xx: Add fatal error check for pm8001_phy_control()

Igor Pylypiv (1):
  scsi: pm80xx: Add fatal error check for pm8001_lu_reset()

 drivers/scsi/pm8001/pm8001_sas.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

-- 
2.40.1.698.g37aff9b760-goog

[PATCH 0/2]

[Finn Thain]

This series removes some duplicate RTC driver code. rtc-m48t59 is tweaked
to bring it into equivalence with the RTC drivers in arch/m68k/mvme*.
Then the latter drivers are removed and platform devices added to make use
of the former.

The second patch depends upon the first, which will require some
coordination between the maintainers of the RTC and m68k subsystems.


Finn Thain (2):
  rtc: m48t59: Accommodate chips that lack a century bit
  m68k: mvme147, mvme16x: Adopt rtc-m48t59 platform driver

 arch/m68k/configs/multi_defconfig   |   1 +
 arch/m68k/configs/mvme147_defconfig |   1 +
 arch/m68k/configs/mvme16x_defconfig |   1 +
 arch/m68k/include/asm/mvme147hw.h   |  19 +---
 arch/m68k/include/asm/mvme16xhw.h   |  18 +--
 arch/m68k/mvme147/config.c          |  54 ++++-----
 arch/m68k/mvme16x/Makefile          |   2 +-
 arch/m68k/mvme16x/config.c          |  56 ++++------
 arch/m68k/mvme16x/rtc.c             | 165 ----------------------------
 drivers/rtc/rtc-m48t59.c            |  31 +++---
 10 files changed, 67 insertions(+), 281 deletions(-)
 delete mode 100644 arch/m68k/mvme16x/rtc.c

-- 
2.39.5

[PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit

[Finn Thain]

The m48t59 driver is needed by both SPARC and MVME systems. Linux on
MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC.
Add support for the MVME convention. Otherwise, the RTC on non-SPARC
systems can only read and write dates between 1900 and 1999.

Tested-by: Daniel Palmer <daniel@0x0f.com>
Signed-off-by: Finn Thain <fthain@linux-m68k.org>
---
 drivers/rtc/rtc-m48t59.c | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
index f0f6b9b6daec..e2d882ea5c2f 100644
--- a/drivers/rtc/rtc-m48t59.c
+++ b/drivers/rtc/rtc-m48t59.c
@@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)
 	return readb(m48t59->ioaddr+ofs);
 }
 
+/*
+ * Sun SPARC machines count years since 1968. MVME machines running Linux
+ * count years since 1970.
+ */
+
+#ifdef CONFIG_SPARC
+#define YEAR0 68
+#else
+#define YEAR0 70
+#endif
+
 /*
  * NOTE: M48T59 only uses BCD mode
  */
@@ -82,10 +93,7 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
 		dev_dbg(dev, "Century bit is enabled\n");
 		tm->tm_year += 100;	/* one century */
 	}
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	tm->tm_year += 68;
-#endif
+	tm->tm_year += YEAR0;
 
 	tm->tm_wday	= bcd2bin(val & 0x07);
 	tm->tm_hour	= bcd2bin(M48T59_READ(M48T59_HOUR) & 0x3F);
@@ -108,10 +116,7 @@ static int m48t59_rtc_set_time(struct device *dev, struct rtc_time *tm)
 	u8 val = 0;
 	int year = tm->tm_year;
 
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	year -= 68;
-#endif
+	year -= YEAR0;
 
 	dev_dbg(dev, "RTC set time %04d-%02d-%02d %02d/%02d/%02d\n",
 		year + 1900, tm->tm_mon, tm->tm_mday,
@@ -163,10 +168,7 @@ static int m48t59_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	M48T59_SET_BITS(M48T59_CNTL_READ, M48T59_CNTL);
 
 	tm->tm_year = bcd2bin(M48T59_READ(M48T59_YEAR));
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	tm->tm_year += 68;
-#endif
+	tm->tm_year += YEAR0;
 	/* tm_mon is 0-11 */
 	tm->tm_mon = bcd2bin(M48T59_READ(M48T59_MONTH)) - 1;
 
@@ -199,10 +201,7 @@ static int m48t59_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	unsigned long flags;
 	int year = tm->tm_year;
 
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	year -= 68;
-#endif
+	year -= YEAR0;
 
 	/* If no irq, we don't support ALARM */
 	if (m48t59->irq == NO_IRQ)
-- 
2.39.5

[PATCH 2/2] m68k: mvme147, mvme16x: Adopt rtc-m48t59 platform driver

[Finn Thain]

Both mvme147 and mvme16x platforms have their own RTC driver
implementations that duplicate functionality provided by the rtc-m48t59
driver. Adopt the rtc-m48t59 driver and remove the other ones.

Tested-by: Daniel Palmer <daniel@0x0f.com>
Signed-off-by: Finn Thain <fthain@linux-m68k.org>
---
 arch/m68k/configs/multi_defconfig   |   1 +
 arch/m68k/configs/mvme147_defconfig |   1 +
 arch/m68k/configs/mvme16x_defconfig |   1 +
 arch/m68k/include/asm/mvme147hw.h   |  19 +---
 arch/m68k/include/asm/mvme16xhw.h   |  18 +--
 arch/m68k/mvme147/config.c          |  54 ++++-----
 arch/m68k/mvme16x/Makefile          |   2 +-
 arch/m68k/mvme16x/config.c          |  56 ++++------
 arch/m68k/mvme16x/rtc.c             | 165 ----------------------------
 9 files changed, 52 insertions(+), 265 deletions(-)
 delete mode 100644 arch/m68k/mvme16x/rtc.c

diff --git a/arch/m68k/configs/multi_defconfig b/arch/m68k/configs/multi_defconfig
index 638df8442c98..617ac93298f3 100644
--- a/arch/m68k/configs/multi_defconfig
+++ b/arch/m68k/configs/multi_defconfig
@@ -506,6 +506,7 @@ CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_MSM6242=m
 CONFIG_RTC_DRV_RP5C01=m
 CONFIG_RTC_DRV_GENERIC=m
+CONFIG_RTC_DRV_M48T59=m
 # CONFIG_VIRTIO_MENU is not set
 # CONFIG_VHOST_MENU is not set
 # CONFIG_IOMMU_SUPPORT is not set
diff --git a/arch/m68k/configs/mvme147_defconfig b/arch/m68k/configs/mvme147_defconfig
index 2248db426081..4a0928b3b842 100644
--- a/arch/m68k/configs/mvme147_defconfig
+++ b/arch/m68k/configs/mvme147_defconfig
@@ -392,6 +392,7 @@ CONFIG_UHID=m
 CONFIG_RTC_CLASS=y
 # CONFIG_RTC_NVMEM is not set
 CONFIG_RTC_DRV_GENERIC=m
+CONFIG_RTC_DRV_M48T59=y
 # CONFIG_VIRTIO_MENU is not set
 # CONFIG_VHOST_MENU is not set
 # CONFIG_IOMMU_SUPPORT is not set
diff --git a/arch/m68k/configs/mvme16x_defconfig b/arch/m68k/configs/mvme16x_defconfig
index 2975b66521f6..481fb2810f1e 100644
--- a/arch/m68k/configs/mvme16x_defconfig
+++ b/arch/m68k/configs/mvme16x_defconfig
@@ -393,6 +393,7 @@ CONFIG_UHID=m
 CONFIG_RTC_CLASS=y
 # CONFIG_RTC_NVMEM is not set
 CONFIG_RTC_DRV_GENERIC=m
+CONFIG_RTC_DRV_M48T59=y
 # CONFIG_VIRTIO_MENU is not set
 # CONFIG_VHOST_MENU is not set
 # CONFIG_IOMMU_SUPPORT is not set
diff --git a/arch/m68k/include/asm/mvme147hw.h b/arch/m68k/include/asm/mvme147hw.h
index e28eb1c0e0bf..2b147ab1d189 100644
--- a/arch/m68k/include/asm/mvme147hw.h
+++ b/arch/m68k/include/asm/mvme147hw.h
@@ -4,24 +4,7 @@
 
 #include <asm/irq.h>
 
-typedef struct {
-	unsigned char
-		ctrl,
-		bcd_sec,
-		bcd_min,
-		bcd_hr,
-		bcd_dow,
-		bcd_dom,
-		bcd_mth,
-		bcd_year;
-} MK48T02;
-
-#define RTC_WRITE	0x80
-#define RTC_READ	0x40
-#define RTC_STOP	0x20
-
-#define m147_rtc ((MK48T02 * volatile)0xfffe07f8)
-
+#define MVME147_RTC_BASE	0xfffe0000
 
 struct pcc_regs {
    volatile u_long	dma_tadr;
diff --git a/arch/m68k/include/asm/mvme16xhw.h b/arch/m68k/include/asm/mvme16xhw.h
index cc7f5ae1220f..ff1126a51fbe 100644
--- a/arch/m68k/include/asm/mvme16xhw.h
+++ b/arch/m68k/include/asm/mvme16xhw.h
@@ -24,23 +24,7 @@ typedef struct {
 
 #define mvmelp   ((*(volatile MVMElpPtr)(MVME_LPR_BASE)))
 
-typedef struct {
-	unsigned char
-		ctrl,
-		bcd_sec,
-		bcd_min,
-		bcd_hr,
-		bcd_dow,
-		bcd_dom,
-		bcd_mth,
-		bcd_year;
-} MK48T08_t, *MK48T08ptr_t;
-
-#define RTC_WRITE	0x80
-#define RTC_READ	0x40
-#define RTC_STOP	0x20
-
-#define MVME_RTC_BASE	0xfffc1ff8
+#define MVME_RTC_BASE	0xfffc0000
 
 #define MVME_I596_BASE	0xfff46000
 
diff --git a/arch/m68k/mvme147/config.c b/arch/m68k/mvme147/config.c
index 8b5dc07f0811..e2560c6d10b4 100644
--- a/arch/m68k/mvme147/config.c
+++ b/arch/m68k/mvme147/config.c
@@ -19,8 +19,9 @@
 #include <linux/linkage.h>
 #include <linux/init.h>
 #include <linux/major.h>
-#include <linux/rtc.h>
 #include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/rtc/m48t59.h>
 
 #include <asm/bootinfo.h>
 #include <asm/bootinfo-vme.h>
@@ -35,13 +36,9 @@
 
 static void mvme147_get_model(char *model);
 extern void mvme147_sched_init(void);
-extern int mvme147_hwclk (int, struct rtc_time *);
 extern void mvme147_reset (void);
 
 
-static int bcd2int (unsigned char b);
-
-
 int __init mvme147_parse_bootinfo(const struct bi_record *bi)
 {
 	uint16_t tag = be16_to_cpu(bi->tag);
@@ -79,7 +76,6 @@ void __init config_mvme147(void)
 {
 	mach_sched_init		= mvme147_sched_init;
 	mach_init_IRQ		= mvme147_init_IRQ;
-	mach_hwclk		= mvme147_hwclk;
 	mach_reset		= mvme147_reset;
 	mach_get_model		= mvme147_get_model;
 
@@ -88,6 +84,27 @@ void __init config_mvme147(void)
 		vme_brdtype = VME_TYPE_MVME147;
 }
 
+static struct resource m48t59_rsrc[] = {
+	DEFINE_RES_MEM(MVME147_RTC_BASE, 0x800),
+};
+
+static struct m48t59_plat_data m48t59_data = {
+	.type = M48T59RTC_TYPE_M48T02,
+};
+
+static int __init mvme147_platform_init(void)
+{
+	if (!MACH_IS_MVME147)
+		return 0;
+
+	platform_device_register_resndata(NULL, "rtc-m48t59", -1,
+					  m48t59_rsrc, ARRAY_SIZE(m48t59_rsrc),
+					  &m48t59_data, sizeof(m48t59_data));
+	return 0;
+}
+
+arch_initcall(mvme147_platform_init);
+
 static u64 mvme147_read_clk(struct clocksource *cs);
 
 static struct clocksource mvme147_clk = {
@@ -160,28 +177,3 @@ static u64 mvme147_read_clk(struct clocksource *cs)
 
 	return ticks;
 }
-
-static int bcd2int (unsigned char b)
-{
-	return ((b>>4)*10 + (b&15));
-}
-
-int mvme147_hwclk(int op, struct rtc_time *t)
-{
-	if (!op) {
-		m147_rtc->ctrl = RTC_READ;
-		t->tm_year = bcd2int (m147_rtc->bcd_year);
-		t->tm_mon  = bcd2int(m147_rtc->bcd_mth) - 1;
-		t->tm_mday = bcd2int (m147_rtc->bcd_dom);
-		t->tm_hour = bcd2int (m147_rtc->bcd_hr);
-		t->tm_min  = bcd2int (m147_rtc->bcd_min);
-		t->tm_sec  = bcd2int (m147_rtc->bcd_sec);
-		m147_rtc->ctrl = 0;
-		if (t->tm_year < 70)
-			t->tm_year += 100;
-	} else {
-		/* FIXME Setting the time is not yet supported */
-		return -EOPNOTSUPP;
-	}
-	return 0;
-}
diff --git a/arch/m68k/mvme16x/Makefile b/arch/m68k/mvme16x/Makefile
index a8a368c2cbea..02f9e4ad8209 100644
--- a/arch/m68k/mvme16x/Makefile
+++ b/arch/m68k/mvme16x/Makefile
@@ -3,4 +3,4 @@
 # Makefile for Linux arch/m68k/mvme16x source directory
 #
 
-obj-y		:= config.o rtc.o
+obj-y		:= config.o
diff --git a/arch/m68k/mvme16x/config.c b/arch/m68k/mvme16x/config.c
index d1fbd1704d65..cca06f75b873 100644
--- a/arch/m68k/mvme16x/config.c
+++ b/arch/m68k/mvme16x/config.c
@@ -21,9 +21,10 @@
 #include <linux/linkage.h>
 #include <linux/init.h>
 #include <linux/major.h>
-#include <linux/rtc.h>
 #include <linux/interrupt.h>
 #include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/rtc/m48t59.h>
 
 #include <asm/bootinfo.h>
 #include <asm/bootinfo-vme.h>
@@ -39,16 +40,10 @@
 
 extern t_bdid mvme_bdid;
 
-static MK48T08ptr_t volatile rtc = (MK48T08ptr_t)MVME_RTC_BASE;
-
 static void mvme16x_get_model(char *model);
 extern void mvme16x_sched_init(void);
-extern int mvme16x_hwclk (int, struct rtc_time *);
 extern void mvme16x_reset (void);
 
-int bcd2int (unsigned char b);
-
-
 unsigned short mvme16x_config;
 EXPORT_SYMBOL(mvme16x_config);
 
@@ -268,7 +263,6 @@ void __init config_mvme16x(void)
 
     mach_sched_init      = mvme16x_sched_init;
     mach_init_IRQ        = mvme16x_init_IRQ;
-    mach_hwclk           = mvme16x_hwclk;
     mach_reset		 = mvme16x_reset;
     mach_get_model       = mvme16x_get_model;
     mach_get_hardware_list = mvme16x_get_hardware_list;
@@ -312,6 +306,27 @@ void __init config_mvme16x(void)
     }
 }
 
+static struct resource m48t59_rsrc[] = {
+	DEFINE_RES_MEM(MVME_RTC_BASE, 0x2000),
+};
+
+static struct m48t59_plat_data m48t59_data = {
+	.type = M48T59RTC_TYPE_M48T08,
+};
+
+static int __init mvme16x_platform_init(void)
+{
+	if (!MACH_IS_MVME16x)
+		return 0;
+
+	platform_device_register_resndata(NULL, "rtc-m48t59", -1,
+					  m48t59_rsrc, ARRAY_SIZE(m48t59_rsrc),
+					  &m48t59_data, sizeof(m48t59_data));
+	return 0;
+}
+
+arch_initcall(mvme16x_platform_init);
+
 static irqreturn_t mvme16x_abort_int (int irq, void *dev_id)
 {
 	unsigned long *new = (unsigned long *)vectors;
@@ -426,28 +441,3 @@ static u64 mvme16x_read_clk(struct clocksource *cs)
 
 	return ticks;
 }
-
-int bcd2int (unsigned char b)
-{
-	return ((b>>4)*10 + (b&15));
-}
-
-int mvme16x_hwclk(int op, struct rtc_time *t)
-{
-	if (!op) {
-		rtc->ctrl = RTC_READ;
-		t->tm_year = bcd2int (rtc->bcd_year);
-		t->tm_mon  = bcd2int(rtc->bcd_mth) - 1;
-		t->tm_mday = bcd2int (rtc->bcd_dom);
-		t->tm_hour = bcd2int (rtc->bcd_hr);
-		t->tm_min  = bcd2int (rtc->bcd_min);
-		t->tm_sec  = bcd2int (rtc->bcd_sec);
-		rtc->ctrl = 0;
-		if (t->tm_year < 70)
-			t->tm_year += 100;
-	} else {
-		/* FIXME Setting the time is not yet supported */
-		return -EOPNOTSUPP;
-	}
-	return 0;
-}
diff --git a/arch/m68k/mvme16x/rtc.c b/arch/m68k/mvme16x/rtc.c
deleted file mode 100644
index ccbaae1125e6..000000000000
--- a/arch/m68k/mvme16x/rtc.c
+++ /dev/null
@@ -1,165 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- *	Real Time Clock interface for Linux on the MVME16x
- *
- * Based on the PC driver by Paul Gortmaker.
- */
-
-#define RTC_VERSION		"1.00"
-
-#include <linux/types.h>
-#include <linux/errno.h>
-#include <linux/miscdevice.h>
-#include <linux/ioport.h>
-#include <linux/capability.h>
-#include <linux/fcntl.h>
-#include <linux/init.h>
-#include <linux/poll.h>
-#include <linux/rtc.h>	/* For struct rtc_time and ioctls, etc */
-#include <linux/bcd.h>
-#include <asm/mvme16xhw.h>
-
-#include <asm/io.h>
-#include <linux/uaccess.h>
-#include <asm/setup.h>
-
-/*
- *	We sponge a minor off of the misc major. No need slurping
- *	up another valuable major dev number for this. If you add
- *	an ioctl, make sure you don't conflict with SPARC's RTC
- *	ioctls.
- */
-
-static const unsigned char days_in_mo[] =
-{0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
-
-static atomic_t rtc_ready = ATOMIC_INIT(1);
-
-static long rtc_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
-{
-	volatile MK48T08ptr_t rtc = (MK48T08ptr_t)MVME_RTC_BASE;
-	unsigned long flags;
-	struct rtc_time wtime;
-	void __user *argp = (void __user *)arg;
-
-	switch (cmd) {
-	case RTC_RD_TIME:	/* Read the time/date from RTC	*/
-	{
-		local_irq_save(flags);
-		/* Ensure clock and real-time-mode-register are accessible */
-		rtc->ctrl = RTC_READ;
-		memset(&wtime, 0, sizeof(struct rtc_time));
-		wtime.tm_sec =  bcd2bin(rtc->bcd_sec);
-		wtime.tm_min =  bcd2bin(rtc->bcd_min);
-		wtime.tm_hour = bcd2bin(rtc->bcd_hr);
-		wtime.tm_mday =  bcd2bin(rtc->bcd_dom);
-		wtime.tm_mon =  bcd2bin(rtc->bcd_mth)-1;
-		wtime.tm_year = bcd2bin(rtc->bcd_year);
-		if (wtime.tm_year < 70)
-			wtime.tm_year += 100;
-		wtime.tm_wday = bcd2bin(rtc->bcd_dow)-1;
-		rtc->ctrl = 0;
-		local_irq_restore(flags);
-		return copy_to_user(argp, &wtime, sizeof wtime) ?
-								-EFAULT : 0;
-	}
-	case RTC_SET_TIME:	/* Set the RTC */
-	{
-		struct rtc_time rtc_tm;
-		unsigned char mon, day, hrs, min, sec, leap_yr;
-		unsigned int yrs;
-
-		if (!capable(CAP_SYS_ADMIN))
-			return -EACCES;
-
-		if (copy_from_user(&rtc_tm, argp, sizeof(struct rtc_time)))
-			return -EFAULT;
-
-		yrs = rtc_tm.tm_year;
-		if (yrs < 1900)
-			yrs += 1900;
-		mon = rtc_tm.tm_mon + 1;   /* tm_mon starts at zero */
-		day = rtc_tm.tm_mday;
-		hrs = rtc_tm.tm_hour;
-		min = rtc_tm.tm_min;
-		sec = rtc_tm.tm_sec;
-
-		leap_yr = ((!(yrs % 4) && (yrs % 100)) || !(yrs % 400));
-
-		if ((mon > 12) || (day == 0))
-			return -EINVAL;
-
-		if (day > (days_in_mo[mon] + ((mon == 2) && leap_yr)))
-			return -EINVAL;
-
-		if ((hrs >= 24) || (min >= 60) || (sec >= 60))
-			return -EINVAL;
-
-		if (yrs >= 2070)
-			return -EINVAL;
-
-		local_irq_save(flags);
-		rtc->ctrl     = RTC_WRITE;
-
-		rtc->bcd_sec  = bin2bcd(sec);
-		rtc->bcd_min  = bin2bcd(min);
-		rtc->bcd_hr   = bin2bcd(hrs);
-		rtc->bcd_dom  = bin2bcd(day);
-		rtc->bcd_mth  = bin2bcd(mon);
-		rtc->bcd_year = bin2bcd(yrs%100);
-
-		rtc->ctrl     = 0;
-		local_irq_restore(flags);
-		return 0;
-	}
-	default:
-		return -EINVAL;
-	}
-}
-
-/*
- * We enforce only one user at a time here with the open/close.
- */
-static int rtc_open(struct inode *inode, struct file *file)
-{
-	if( !atomic_dec_and_test(&rtc_ready) )
-	{
-		atomic_inc( &rtc_ready );
-		return -EBUSY;
-	}
-	return 0;
-}
-
-static int rtc_release(struct inode *inode, struct file *file)
-{
-	atomic_inc( &rtc_ready );
-	return 0;
-}
-
-/*
- *	The various file operations we support.
- */
-
-static const struct file_operations rtc_fops = {
-	.unlocked_ioctl	= rtc_ioctl,
-	.open		= rtc_open,
-	.release	= rtc_release,
-	.llseek		= noop_llseek,
-};
-
-static struct miscdevice rtc_dev=
-{
-	.minor =	RTC_MINOR,
-	.name =		"rtc",
-	.fops =		&rtc_fops
-};
-
-static int __init rtc_MK48T08_init(void)
-{
-	if (!MACH_IS_MVME16x)
-		return -ENODEV;
-
-	pr_info("MK48T08 Real Time Clock Driver v%s\n", RTC_VERSION);
-	return misc_register(&rtc_dev);
-}
-device_initcall(rtc_MK48T08_init);
-- 
2.39.5

Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit

[Geert Uytterhoeven]

Hi Finn,

On Thu, Oct 3, 2024 at 5:27 AM Finn Thain <fthain@linux-m68k.org> wrote:
> The m48t59 driver is needed by both SPARC and MVME systems. Linux on
> MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC.
> Add support for the MVME convention. Otherwise, the RTC on non-SPARC
> systems can only read and write dates between 1900 and 1999.
>
> Tested-by: Daniel Palmer <daniel@0x0f.com>
> Signed-off-by: Finn Thain <fthain@linux-m68k.org>

Thanks for your patch!

> --- a/drivers/rtc/rtc-m48t59.c
> +++ b/drivers/rtc/rtc-m48t59.c
> @@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)
>         return readb(m48t59->ioaddr+ofs);
>  }
>
> +/*
> + * Sun SPARC machines count years since 1968. MVME machines running Linux
> + * count years since 1970.
> + */
> +
> +#ifdef CONFIG_SPARC
> +#define YEAR0 68
> +#else
 +#define YEAR0 70
> +#endif

This causes a change in behavior on other non-SPARC platforms,
if any out-of-tree platform exists that uses this driver.

So I'd rather use:

    #elif defined(CONFIG_VME)
    #define YEAR0 70
    #else
    #define YEAR0 0
    #endif

> +
>  /*
>   * NOTE: M48T59 only uses BCD mode
>   */
> @@ -82,10 +93,7 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
>                 dev_dbg(dev, "Century bit is enabled\n");
>                 tm->tm_year += 100;     /* one century */
>         }
> -#ifdef CONFIG_SPARC
> -       /* Sun SPARC machines count years since 1968 */
> -       tm->tm_year += 68;
> -#endif
> +       tm->tm_year += YEAR0;

Upon closer look, the driver uses platform data, so a better solution
would be to add the year0 offset to struct m48t59_plat_data.

Another suggestion for improvement, not related to this patch,
would be to differentiate among M48T59, M48T02, and M48T08 by using
platform_driver.id_table and platform_device_id.driver_data, instead
of m48t59_plat_data.type.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit

[Alexandre Belloni]

Hello,

On 03/10/2024 13:23:22+1000, Finn Thain wrote:
> The m48t59 driver is needed by both SPARC and MVME systems. Linux on
> MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC.
> Add support for the MVME convention. Otherwise, the RTC on non-SPARC
> systems can only read and write dates between 1900 and 1999.
> 
> Tested-by: Daniel Palmer <daniel@0x0f.com>
> Signed-off-by: Finn Thain <fthain@linux-m68k.org>
> ---
>  drivers/rtc/rtc-m48t59.c | 31 +++++++++++++++----------------
>  1 file changed, 15 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
> index f0f6b9b6daec..e2d882ea5c2f 100644
> --- a/drivers/rtc/rtc-m48t59.c
> +++ b/drivers/rtc/rtc-m48t59.c
> @@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)
>  	return readb(m48t59->ioaddr+ofs);
>  }
>  
> +/*
> + * Sun SPARC machines count years since 1968. MVME machines running Linux
> + * count years since 1970.
> + */
> +
> +#ifdef CONFIG_SPARC
> +#define YEAR0 68
> +#else
> +#define YEAR0 70
> +#endif
> +
>  /*
>   * NOTE: M48T59 only uses BCD mode
>   */
> @@ -82,10 +93,7 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
>  		dev_dbg(dev, "Century bit is enabled\n");
>  		tm->tm_year += 100;	/* one century */
>  	}
> -#ifdef CONFIG_SPARC
> -	/* Sun SPARC machines count years since 1968 */
> -	tm->tm_year += 68;
> -#endif
> +	tm->tm_year += YEAR0;
>  

I'm super happy to see someone working on this, while you are it, can
you use m48t59->rtc->start_secs and m48t59->rtc->set_start_time in probe
instead of offsetting tm_year in read_time/set_time so we can later use
device tree or any other mechanism to extend the range?

It is super funny because I was telling Geert that I wanted to get rid
of this #ifdef CONFIG_SPARC two weeks ago at LPC. That could indeed then
come from platform data.

>  	tm->tm_wday	= bcd2bin(val & 0x07);
>  	tm->tm_hour	= bcd2bin(M48T59_READ(M48T59_HOUR) & 0x3F);
> @@ -108,10 +116,7 @@ static int m48t59_rtc_set_time(struct device *dev, struct rtc_time *tm)
>  	u8 val = 0;
>  	int year = tm->tm_year;
>  
> -#ifdef CONFIG_SPARC
> -	/* Sun SPARC machines count years since 1968 */
> -	year -= 68;
> -#endif
> +	year -= YEAR0;
>  
>  	dev_dbg(dev, "RTC set time %04d-%02d-%02d %02d/%02d/%02d\n",
>  		year + 1900, tm->tm_mon, tm->tm_mday,
> @@ -163,10 +168,7 @@ static int m48t59_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
>  	M48T59_SET_BITS(M48T59_CNTL_READ, M48T59_CNTL);
>  
>  	tm->tm_year = bcd2bin(M48T59_READ(M48T59_YEAR));
> -#ifdef CONFIG_SPARC
> -	/* Sun SPARC machines count years since 1968 */
> -	tm->tm_year += 68;
> -#endif
> +	tm->tm_year += YEAR0;
>  	/* tm_mon is 0-11 */
>  	tm->tm_mon = bcd2bin(M48T59_READ(M48T59_MONTH)) - 1;
>  
> @@ -199,10 +201,7 @@ static int m48t59_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
>  	unsigned long flags;
>  	int year = tm->tm_year;
>  
> -#ifdef CONFIG_SPARC
> -	/* Sun SPARC machines count years since 1968 */
> -	year -= 68;
> -#endif
> +	year -= YEAR0;
>  
>  	/* If no irq, we don't support ALARM */
>  	if (m48t59->irq == NO_IRQ)
> -- 
> 2.39.5
> 

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit

[Finn Thain]

On Thu, 3 Oct 2024, Geert Uytterhoeven wrote:

> Thanks for your patch!
> 

Thanks for your review.

> > --- a/drivers/rtc/rtc-m48t59.c
> > +++ b/drivers/rtc/rtc-m48t59.c
> > @@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)
> >         return readb(m48t59->ioaddr+ofs);
> >  }
> >
> > +/*
> > + * Sun SPARC machines count years since 1968. MVME machines running Linux
> > + * count years since 1970.
> > + */
> > +
> > +#ifdef CONFIG_SPARC
> > +#define YEAR0 68
> > +#else
>  +#define YEAR0 70
> > +#endif
> 
> This causes a change in behavior on other non-SPARC platforms,
> if any out-of-tree platform exists that uses this driver.
> 

I'm unaware of any need to support out-of-tree code. Do you see think such 
a requirement would be feasible somehow? Is this documented somewhere?

> So I'd rather use:
> 
>     #elif defined(CONFIG_VME)
>     #define YEAR0 70
>     #else
>     #define YEAR0 0
>     #endif
> 

That is a Y2K bug, right?

> > +
> >  /*
> >   * NOTE: M48T59 only uses BCD mode
> >   */
> > @@ -82,10 +93,7 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
> >                 dev_dbg(dev, "Century bit is enabled\n");
> >                 tm->tm_year += 100;     /* one century */
> >         }
> > -#ifdef CONFIG_SPARC
> > -       /* Sun SPARC machines count years since 1968 */
> > -       tm->tm_year += 68;
> > -#endif
> > +       tm->tm_year += YEAR0;
> 
> Upon closer look, the driver uses platform data, so a better solution 
> would be to add the year0 offset to struct m48t59_plat_data.
> 

I agree.

> Another suggestion for improvement, not related to this patch, would be 
> to differentiate among M48T59, M48T02, and M48T08 by using 
> platform_driver.id_table and platform_device_id.driver_data, instead of 
> m48t59_plat_data.type.
> 

Yes, that's well out-of-scope I think.

Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit

[Finn Thain]

On Thu, 3 Oct 2024, Alexandre Belloni wrote:

> On 03/10/2024 13:23:22+1000, Finn Thain wrote:
> > The m48t59 driver is needed by both SPARC and MVME systems. Linux on
> > MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC.
> > Add support for the MVME convention. Otherwise, the RTC on non-SPARC
> > systems can only read and write dates between 1900 and 1999.
> > 
> > Tested-by: Daniel Palmer <daniel@0x0f.com>
> > Signed-off-by: Finn Thain <fthain@linux-m68k.org>
> > ---
> >  drivers/rtc/rtc-m48t59.c | 31 +++++++++++++++----------------
> >  1 file changed, 15 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
> > index f0f6b9b6daec..e2d882ea5c2f 100644
> > --- a/drivers/rtc/rtc-m48t59.c
> > +++ b/drivers/rtc/rtc-m48t59.c
> > @@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)
> >  	return readb(m48t59->ioaddr+ofs);
> >  }
> >  
> > +/*
> > + * Sun SPARC machines count years since 1968. MVME machines running Linux
> > + * count years since 1970.
> > + */
> > +
> > +#ifdef CONFIG_SPARC
> > +#define YEAR0 68
> > +#else
> > +#define YEAR0 70
> > +#endif
> > +
> >  /*
> >   * NOTE: M48T59 only uses BCD mode
> >   */
> > @@ -82,10 +93,7 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
> >  		dev_dbg(dev, "Century bit is enabled\n");
> >  		tm->tm_year += 100;	/* one century */
> >  	}
> > -#ifdef CONFIG_SPARC
> > -	/* Sun SPARC machines count years since 1968 */
> > -	tm->tm_year += 68;
> > -#endif
> > +	tm->tm_year += YEAR0;
> >  
> 
> I'm super happy to see someone working on this, while you are it, can 
> you use m48t59->rtc->start_secs and m48t59->rtc->set_start_time in probe 
> instead of offsetting tm_year in read_time/set_time so we can later use 
> device tree or any other mechanism to extend the range?
> 

Sure, I will look into it.

> It is super funny because I was telling Geert that I wanted to get rid 
> of this #ifdef CONFIG_SPARC two weeks ago at LPC. That could indeed then 
> come from platform data.
> 

I can't test any patches on SPARC, unless there's some way to do so using 
QEMU that would satisfy maintainers. (I rely on Daniel to test my patches 
on an MVME147 system.)

Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit

[Finn Thain]

On Thu, 3 Oct 2024, Alexandre Belloni wrote:

> 
> ... while you are it, can you use m48t59->rtc->start_secs and 
> m48t59->rtc->set_start_time in probe instead of offsetting tm_year in 
> read_time/set_time so we can later use device tree or any other 
> mechanism to extend the range?
> 

That didn't work out as I'd hoped. I booted a patched kernel (diff below) 
under qemu-system-sparc64:

~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do 
date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
Thu Jan  1 01:01:00 UTC 1970
Thu Jan  1 01:01:00 1970  0.000000 seconds

Fri Jan  1 01:01:00 UTC 1971
Tue Nov 24 18:32:44 1998  0.000000 seconds

Fri Jan  1 01:01:00 UTC 1999
Tue Nov 24 18:32:44 2026  0.000000 seconds

Sat Jan  1 01:01:00 UTC 2000
Sun Jan  2 23:29:16 2000  0.000000 seconds

Mon Jan  1 01:01:00 UTC 2024
Tue Jan  2 23:29:16 2024  0.000000 seconds

Wed Jan  1 01:01:00 UTC 2025
Thu Jan  2 23:29:16 2025  0.000000 seconds

Sun Jan  1 01:01:00 UTC 2068
hwclock: RTC_SET_TIME: Numerical result out of range

Tue Jan  1 01:01:00 UTC 2069
hwclock: RTC_SET_TIME: Numerical result out of range

~ # 

Here's the result from an unpatched kernel (v6.11):

~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do 
date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
Thu Jan  1 01:01:00 UTC 1970
Thu Jan  1 01:01:00 1970  0.000000 seconds

Fri Jan  1 01:01:00 UTC 1971
Fri Jan  1 01:01:00 1971  0.000000 seconds

Fri Jan  1 01:01:00 UTC 1999
Fri Jan  1 01:01:01 1999  0.000000 seconds

Sat Jan  1 01:01:00 UTC 2000
Sat Jan  1 01:01:00 2000  0.000000 seconds

Mon Jan  1 01:01:00 UTC 2024
Mon Jan  1 01:01:00 2024  0.000000 seconds

Wed Jan  1 01:01:00 UTC 2025
Wed Jan  1 01:01:00 2025  0.000000 seconds

Sun Jan  1 01:01:00 UTC 2068
hwclock: RTC_RD_TIME: Invalid argument

Tue Jan  1 01:01:00 UTC 2069
hwclock: RTC_RD_TIME: Invalid argument

~ # 


I'm afraid I don't see how we might avoid adding/subtracting in 
read_time/set_time given that we must avoid messing up the present date 
when users boot into an upgraded kernel.


diff --git a/arch/sparc/kernel/time_32.c b/arch/sparc/kernel/time_32.c
index 08bbdc458596..41ae3d1aa12e 100644
--- a/arch/sparc/kernel/time_32.c
+++ b/arch/sparc/kernel/time_32.c
@@ -255,6 +255,7 @@ static void mostek_write_byte(struct device *dev, u32 ofs, u8 val)
 static struct m48t59_plat_data m48t59_data = {
 	.read_byte = mostek_read_byte,
 	.write_byte = mostek_write_byte,
+	.start_year = 1968,
 };
 
 /* resource is set at runtime */
diff --git a/arch/sparc/kernel/time_64.c b/arch/sparc/kernel/time_64.c
index 60f1c8cc5363..eceb3fadb71a 100644
--- a/arch/sparc/kernel/time_64.c
+++ b/arch/sparc/kernel/time_64.c
@@ -544,6 +544,7 @@ static void mostek_write_byte(struct device *dev, u32 ofs, u8 val)
 static struct m48t59_plat_data m48t59_data = {
 	.read_byte	= mostek_read_byte,
 	.write_byte	= mostek_write_byte,
+	.start_year	= 1968,
 };
 
 static struct platform_device m48t59_rtc = {
diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
index f0f6b9b6daec..d7e1f79cd52b 100644
--- a/drivers/rtc/rtc-m48t59.c
+++ b/drivers/rtc/rtc-m48t59.c
@@ -82,10 +82,6 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
 		dev_dbg(dev, "Century bit is enabled\n");
 		tm->tm_year += 100;	/* one century */
 	}
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	tm->tm_year += 68;
-#endif
 
 	tm->tm_wday	= bcd2bin(val & 0x07);
 	tm->tm_hour	= bcd2bin(M48T59_READ(M48T59_HOUR) & 0x3F);
@@ -108,11 +104,6 @@ static int m48t59_rtc_set_time(struct device *dev, struct rtc_time *tm)
 	u8 val = 0;
 	int year = tm->tm_year;
 
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	year -= 68;
-#endif
-
 	dev_dbg(dev, "RTC set time %04d-%02d-%02d %02d/%02d/%02d\n",
 		year + 1900, tm->tm_mon, tm->tm_mday,
 		tm->tm_hour, tm->tm_min, tm->tm_sec);
@@ -163,10 +154,7 @@ static int m48t59_rtc_readalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	M48T59_SET_BITS(M48T59_CNTL_READ, M48T59_CNTL);
 
 	tm->tm_year = bcd2bin(M48T59_READ(M48T59_YEAR));
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	tm->tm_year += 68;
-#endif
+
 	/* tm_mon is 0-11 */
 	tm->tm_mon = bcd2bin(M48T59_READ(M48T59_MONTH)) - 1;
 
@@ -199,11 +187,6 @@ static int m48t59_rtc_setalarm(struct device *dev, struct rtc_wkalrm *alrm)
 	unsigned long flags;
 	int year = tm->tm_year;
 
-#ifdef CONFIG_SPARC
-	/* Sun SPARC machines count years since 1968 */
-	year -= 68;
-#endif
-
 	/* If no irq, we don't support ALARM */
 	if (m48t59->irq == NO_IRQ)
 		return -EIO;
@@ -458,6 +441,10 @@ static int m48t59_rtc_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, m48t59);
 
 	m48t59->rtc->ops = &m48t59_rtc_ops;
+	m48t59->rtc->range_min = mktime64(1900, 1, 1, 0, 0, 0);
+	m48t59->rtc->range_max = mktime64(1999, 12, 31, 23, 59, 59);
+	m48t59->rtc->start_secs = mktime64(pdata->start_year, 1, 1, 0, 0, 0);
+	m48t59->rtc->set_start_time = true;
 
 	nvmem_cfg.size = pdata->offset;
 	ret = devm_rtc_nvmem_register(m48t59->rtc, &nvmem_cfg);
diff --git a/include/linux/rtc/m48t59.h b/include/linux/rtc/m48t59.h
index 9465d5405fe2..b01c514d7079 100644
--- a/include/linux/rtc/m48t59.h
+++ b/include/linux/rtc/m48t59.h
@@ -56,6 +56,9 @@ struct m48t59_plat_data {
 	void __iomem *ioaddr;
 	/* offset to RTC registers, automatically set according to the type */
 	unsigned int offset;
+
+	/* value to be used to initialize rtc->start_secs */
+	time64_t start_year;
 };
 
 #endif /* _LINUX_RTC_M48T59_H_ */

Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century bit

[Alexandre Belloni]

On 05/10/2024 14:23:28+1000, Finn Thain wrote:
> 
> On Thu, 3 Oct 2024, Alexandre Belloni wrote:
> 
> > 
> > ... while you are it, can you use m48t59->rtc->start_secs and 
> > m48t59->rtc->set_start_time in probe instead of offsetting tm_year in 
> > read_time/set_time so we can later use device tree or any other 
> > mechanism to extend the range?
> > 
> 
> That didn't work out as I'd hoped. I booted a patched kernel (diff below) 
> under qemu-system-sparc64:
> 
> ~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do 
> date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
> Thu Jan  1 01:01:00 UTC 1970
> Thu Jan  1 01:01:00 1970  0.000000 seconds
> 
> Fri Jan  1 01:01:00 UTC 1971
> Tue Nov 24 18:32:44 1998  0.000000 seconds
> 
> Fri Jan  1 01:01:00 UTC 1999
> Tue Nov 24 18:32:44 2026  0.000000 seconds
> 
> Sat Jan  1 01:01:00 UTC 2000
> Sun Jan  2 23:29:16 2000  0.000000 seconds
> 
> Mon Jan  1 01:01:00 UTC 2024
> Tue Jan  2 23:29:16 2024  0.000000 seconds
> 
> Wed Jan  1 01:01:00 UTC 2025
> Thu Jan  2 23:29:16 2025  0.000000 seconds
> 
> Sun Jan  1 01:01:00 UTC 2068
> hwclock: RTC_SET_TIME: Numerical result out of range
> 
> Tue Jan  1 01:01:00 UTC 2069
> hwclock: RTC_SET_TIME: Numerical result out of range
> 
> ~ # 
> 
> Here's the result from an unpatched kernel (v6.11):
> 
> ~ # for yyyy in 1970 1971 1999 2000 2024 2025 2068 2069 ; do 
> date 01010101$yyyy ; hwclock --systohc --utc && hwclock --utc ; echo ; done
> Thu Jan  1 01:01:00 UTC 1970
> Thu Jan  1 01:01:00 1970  0.000000 seconds
> 
> Fri Jan  1 01:01:00 UTC 1971
> Fri Jan  1 01:01:00 1971  0.000000 seconds
> 
> Fri Jan  1 01:01:00 UTC 1999
> Fri Jan  1 01:01:01 1999  0.000000 seconds
> 
> Sat Jan  1 01:01:00 UTC 2000
> Sat Jan  1 01:01:00 2000  0.000000 seconds
> 
> Mon Jan  1 01:01:00 UTC 2024
> Mon Jan  1 01:01:00 2024  0.000000 seconds
> 
> Wed Jan  1 01:01:00 UTC 2025
> Wed Jan  1 01:01:00 2025  0.000000 seconds
> 
> Sun Jan  1 01:01:00 UTC 2068
> hwclock: RTC_RD_TIME: Invalid argument
> 
> Tue Jan  1 01:01:00 UTC 2069
> hwclock: RTC_RD_TIME: Invalid argument
> 
> ~ # 
> 
> 
> I'm afraid I don't see how we might avoid adding/subtracting in 
> read_time/set_time given that we must avoid messing up the present date 
> when users boot into an upgraded kernel.

I'm pretty sure this is avoidable as this is exactly what the offset
mechanism is trying to achieve. I guess the issue is in the RTC core
because both range_min and start_secs are negative which has never been
tested. My plan was to have unit tests for this but this never
happened...


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[PATCH 0/2]

[Patrice Chotard]

stm32mp: Restore STM32MP257F-EV1 boot

This series is restoring STM32MP257F-EV1 boot :
  _ Fix usart2 clock frequency
  _ Fix board_get_usable_ram_top()



Patrice Chotard (2):
  stm32mp: Fix board_get_usable_ram_top()
  ARM: dts: stm32: Update ck_flexgen_08 frequency.

 arch/arm/dts/stm32mp251.dtsi      | 2 +-
 arch/arm/mach-stm32mp/dram_init.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.25.1

Re: [PATCH 0/2]

[Patrice CHOTARD]

Don't take care of this series, i will resend it with correct cover letter title

Sorry
Patrice

On 1/9/25 11:18, Patrice Chotard wrote:
> stm32mp: Restore STM32MP257F-EV1 boot
> 
> This series is restoring STM32MP257F-EV1 boot :
>   _ Fix usart2 clock frequency
>   _ Fix board_get_usable_ram_top()
> 
> 
> 
> Patrice Chotard (2):
>   stm32mp: Fix board_get_usable_ram_top()
>   ARM: dts: stm32: Update ck_flexgen_08 frequency.
> 
>  arch/arm/dts/stm32mp251.dtsi      | 2 +-
>  arch/arm/mach-stm32mp/dram_init.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 

[PATCH 0/2]

[luyulin]

  This patch introduces a driver for the Eswin eic7700 SoC pinctrl
  controller, adding support for the pinctrl functionality in the Linux
  kernel. The driver provides basic functionality to manage and control
  the pinctrl signals for the eic7700 SoC.

  The driver integrates with the Linux pinctrl subsystem, enabling kernel
  code to trigger pinctrl operations on hardware and ensuring support for
  pin multiplexing and pin configuration.

  Features:

    Implements support for the Eswin eic7700 SoC pinctrl controller.
    Provides API to manage pinctrl for the eic7700 SoC.
    Integration with the Linux pinctrl subsystem for consistency and
    scalability.

  Supported chips:
    Eswin eic7700 SoC.

  Test:
    I tested this patch on the Sifive HiFive Premier P550 (which uses
    the EIC7700 SoC), including system boot, networking, EMMC, display,
    and other peripherals. The drivers for these modules all use the
    pinctrl module, so this verifies that this pinctrl driver
    patch is working properly.

luyulin (2):
  dt-bindings: pinctrl: eswin: Document for eic7700 SoC
  pinctrl: eswin: Add eic7700 pinctrl driver

 .../pinctrl/eswin,eic7700-pinctrl.yaml        | 156 ++++
 drivers/pinctrl/Kconfig                       |  11 +
 drivers/pinctrl/Makefile                      |   1 +
 drivers/pinctrl/pinctrl-eic7700.c             | 701 ++++++++++++++++++
 4 files changed, 869 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/eswin,eic7700-pinctrl.yaml
 create mode 100644 drivers/pinctrl/pinctrl-eic7700.c

-- 
2.25.1

[PATCH 0/2]

[Rex Chen]

[PATCH 1/2]
Function mmc_sdio_alive() check if sd device alive by cmd7, but SPI mode
cmd7 unavailable, so replaced by check if can read CCCR register success.
[PATCH 2/2]
SPI multiple read operation doesn't need to read crc ack, so remove it.

Rex Chen (2):
  mmc: core: SPI mode remove cmd7
  mmc: mmc_spi: multiple block read remove read crc ack

 drivers/mmc/core/sdio.c    | 8 +++++++-
 drivers/mmc/host/mmc_spi.c | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

-- 
2.25.1

[PATCH 0/2]

[Sergey Shtylyov]

The nfs_client::cl_lease_time field (as well as the jiffies variable it's
used with) is declared as *unsigned long*, which is 32-bit type on 32-bit
arches and 64-bit type on 64-bit arches. When nfs4_set_lease_period() that
sets nfs_client::cl_lease_time is called, 32-bit nfs_fsinfo::lease_time
field is multiplied by HZ -- that might overflow before being implicitly
cast to *unsigned long*.  Actually, there's no need to multiply by HZ at
all the call sites of nfs4_set_lease_period() -- it makes more sense to do
that once, inside that function.  That way, we can avoid such overflow by
capping the lease period at e.g. 1 hour before multipying it by HZ...

The patches below are against the linux-next branch of Trond Myklebust's
linux-nfs.git repo.

Sergey Shtylyov (2):
  NFSv4: pass lease period in seconds to nfs4_set_lease_period()
  NFSv4: limit lease period in nfs4_set_lease_period()

 fs/nfs/nfs4_fs.h    |  3 +--
 fs/nfs/nfs4proc.c   |  2 +-
 fs/nfs/nfs4renewd.c | 15 ++++++++++++---
 fs/nfs/nfs4state.c  |  2 +-
 4 files changed, 15 insertions(+), 7 deletions(-)

-- 
2.52.0

Re: [PATCH 0/2]

[Sergey Shtylyov]

Argh, I forgot to finish the subject! :-/ I'll repost...