Add functionality for accessing device hardware registers, loading
firmware bundles, and accessing the device's internal flash memory,
and use it to implement the devlink flash functionality.

Patch breakdown:
Patch1: helpers to access hardware registers
Patch2: low level functions to access flash memory
Patch3: support to load firmware bundles
Patch4: refactoring device initialization and helper functions
        for stopping and resuming device normal operation
Patch5: devlink .flash_update callback implementation

Ivan Vecera (5):
  dpll: zl3073x: Add functions to access hardware registers
  dpll: zl3073x: Add low-level flash functions
  dpll: zl3073x: Add firmware loading functionality
  dpll: zl3073x: Refactor DPLL initialization
  dpll: zl3073x: Implement devlink flash callback

 Documentation/networking/devlink/zl3073x.rst |  14 +
 drivers/dpll/zl3073x/Makefile                |   2 +-
 drivers/dpll/zl3073x/core.c                  | 362 +++++++---
 drivers/dpll/zl3073x/core.h                  |  32 +
 drivers/dpll/zl3073x/devlink.c               |  92 ++-
 drivers/dpll/zl3073x/devlink.h               |   3 +
 drivers/dpll/zl3073x/flash.c                 | 674 +++++++++++++++++++
 drivers/dpll/zl3073x/flash.h                 |  29 +
 drivers/dpll/zl3073x/fw.c                    | 495 ++++++++++++++
 drivers/dpll/zl3073x/fw.h                    |  52 ++
 drivers/dpll/zl3073x/regs.h                  |  51 ++
 11 files changed, 1715 insertions(+), 91 deletions(-)
 create mode 100644 drivers/dpll/zl3073x/flash.c
 create mode 100644 drivers/dpll/zl3073x/flash.h
 create mode 100644 drivers/dpll/zl3073x/fw.c
 create mode 100644 drivers/dpll/zl3073x/fw.h

-- 
2.49.1

On 25. 07. 25 5:41 odp., Ivan Vecera wrote:
> Add functionality for accessing device hardware registers, loading
> firmware bundles, and accessing the device's internal flash memory,
> and use it to implement the devlink flash functionality.
> 
> Patch breakdown:
> Patch1: helpers to access hardware registers
> Patch2: low level functions to access flash memory
> Patch3: support to load firmware bundles
> Patch4: refactoring device initialization and helper functions
>          for stopping and resuming device normal operation
> Patch5: devlink .flash_update callback implementation
> 
> Ivan Vecera (5):
>    dpll: zl3073x: Add functions to access hardware registers
>    dpll: zl3073x: Add low-level flash functions
>    dpll: zl3073x: Add firmware loading functionality
>    dpll: zl3073x: Refactor DPLL initialization
>    dpll: zl3073x: Implement devlink flash callback
> 
>   Documentation/networking/devlink/zl3073x.rst |  14 +
>   drivers/dpll/zl3073x/Makefile                |   2 +-
>   drivers/dpll/zl3073x/core.c                  | 362 +++++++---
>   drivers/dpll/zl3073x/core.h                  |  32 +
>   drivers/dpll/zl3073x/devlink.c               |  92 ++-
>   drivers/dpll/zl3073x/devlink.h               |   3 +
>   drivers/dpll/zl3073x/flash.c                 | 674 +++++++++++++++++++
>   drivers/dpll/zl3073x/flash.h                 |  29 +
>   drivers/dpll/zl3073x/fw.c                    | 495 ++++++++++++++
>   drivers/dpll/zl3073x/fw.h                    |  52 ++
>   drivers/dpll/zl3073x/regs.h                  |  51 ++
>   11 files changed, 1715 insertions(+), 91 deletions(-)
>   create mode 100644 drivers/dpll/zl3073x/flash.c
>   create mode 100644 drivers/dpll/zl3073x/flash.h
>   create mode 100644 drivers/dpll/zl3073x/fw.c
>   create mode 100644 drivers/dpll/zl3073x/fw.h

Self nacked, need to fix warnings found by clang (not identified by
gcc).

Ivan

On Fri, 25 Jul 2025 19:18:55 +0200 Ivan Vecera wrote:
> Self nacked, need to fix warnings found by clang (not identified by
> gcc).

Thanks for the note, I suppose you updated the patchwork state
yourself? Please prefer using pw-bot commands in networking and bpf.

(BTW net-next is closed already)

Quoting documentation:

  Updating patch status
  ~~~~~~~~~~~~~~~~~~~~~
  
  Contributors and reviewers do not have the permissions to update patch
  state directly in patchwork. Patchwork doesn't expose much information
  about the history of the state of patches, therefore having multiple
  people update the state leads to confusion.
  
  Instead of delegating patchwork permissions netdev uses a simple mail
  bot which looks for special commands/lines within the emails sent to
  the mailing list. For example to mark a series as Changes Requested
  one needs to send the following line anywhere in the email thread::
  
    pw-bot: changes-requested
  
  As a result the bot will set the entire series to Changes Requested.
  This may be useful when author discovers a bug in their own series
  and wants to prevent it from getting applied.
  
  The use of the bot is entirely optional, if in doubt ignore its existence
  completely. Maintainers will classify and update the state of the patches
  themselves. No email should ever be sent to the list with the main purpose
  of communicating with the bot, the bot commands should be seen as metadata.
  
  The use of the bot is restricted to authors of the patches (the ``From:``
  header on patch submission and command must match!), maintainers of
  the modified code according to the MAINTAINERS file (again, ``From:``
  must match the MAINTAINERS entry) and a handful of senior reviewers.
  
  Bot records its activity here:
  
    https://netdev.bots.linux.dev/pw-bot.html
  
See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#updating-patch-status

Hi Kuba,

On 25. 07. 25 7:42 odp., Jakub Kicinski wrote:
> On Fri, 25 Jul 2025 19:18:55 +0200 Ivan Vecera wrote:
>> Self nacked, need to fix warnings found by clang (not identified by
>> gcc).
> 
> Thanks for the note, I suppose you updated the patchwork state
> yourself? Please prefer using pw-bot commands in networking and bpf.

Will do next time, thanks for the note.

> (BTW net-next is closed already)

Oops, I missed this... will send v2 once the net-next will be open.

Thanks,
Ivan

> Quoting documentation:
> 
>    Updating patch status
>    ~~~~~~~~~~~~~~~~~~~~~
>    
>    Contributors and reviewers do not have the permissions to update patch
>    state directly in patchwork. Patchwork doesn't expose much information
>    about the history of the state of patches, therefore having multiple
>    people update the state leads to confusion.
>    
>    Instead of delegating patchwork permissions netdev uses a simple mail
>    bot which looks for special commands/lines within the emails sent to
>    the mailing list. For example to mark a series as Changes Requested
>    one needs to send the following line anywhere in the email thread::
>    
>      pw-bot: changes-requested
>    
>    As a result the bot will set the entire series to Changes Requested.
>    This may be useful when author discovers a bug in their own series
>    and wants to prevent it from getting applied.
>    
>    The use of the bot is entirely optional, if in doubt ignore its existence
>    completely. Maintainers will classify and update the state of the patches
>    themselves. No email should ever be sent to the list with the main purpose
>    of communicating with the bot, the bot commands should be seen as metadata.
>    
>    The use of the bot is restricted to authors of the patches (the ``From:``
>    header on patch submission and command must match!), maintainers of
>    the modified code according to the MAINTAINERS file (again, ``From:``
>    must match the MAINTAINERS entry) and a handful of senior reviewers.
>    
>    Bot records its activity here:
>    
>      https://netdev.bots.linux.dev/pw-bot.html
>    
> See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#updating-patch-status
>