Skip to content
Snippets Groups Projects
  1. Sep 25, 2023
  2. Sep 18, 2023
  3. Sep 15, 2023
  4. Sep 14, 2023
  5. Sep 08, 2023
    • GitBot's avatar
      Integrate gitlab-ci/remove-release-name-from-deploy-target and 10 more · efe5891a
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@f2a29f53
      
      Refactoring: remove RELEASE_NAME from deploy targets
      
      Append it to the configured target at the deploy class level instead.
      This removes the need for eval'ing the variables before usage.
      RELEASE_NAME can be used directly at the class level because it is known
      from build-version.env.
      
      This makes the deploy behavior identical to the Azure stage.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@e136e5e2
      
      Remove top-level "release" folder from package
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@1d5e479f
      
      Define MACHINE variable on job level
      
      Instead of passing MACHINE from stage to stage or loading it from
      testdata.json, use the original value from the Jinja2 loop and set it
      directly for each job where it is used.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@cdd47023
      
      Introduce separate variables to set RELEASE_NAME and RELEASE_VERSION
      
      The expressions to calculate RELEASE_NAME and RELEASE_VERSION cannot be
      stored within these variables themseselves. If set on the trigger level,
      they would override the calculated values in build-version.env then,
      as trigger variables always have the highest precedence.
      
      Use separate variables RELEASE_VERSION_EXPRESSION and
      RELEASE_NAME_EXPRESSION to define how RELEASE_VERSION and RELEASE_NAME
      are calculated instead.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@372d192b
      
      Use RELEASE_VERSION and RELEASE_NAME from build-version job
      
      Instead of passing these variables from stage to stage or regenerating
      their values in later stages, use the ones set in the build-version job
      at all places.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@cad30c20
      
      Remove RELEASE_SUFFIX variable
      
      The RELEASE_NAME variable can be set directly now, so there's no need to
      have a dedicated RELEASE_SUFFIX anymore. A previous configuration like
      
        RELEASE_SUFFIX: "-custom"
      
      can now be achieved using:
      
        RELEASE_NAME: "Yocto-${RELEASE_VERSION}-custom"
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@922f49f8
      
      Add yocto version job
      
      This adds a machine-independent job "build-version" which populates the
      RELEASE_VERSION and RELEASE_NAME variables, so that following jobs can
      use these without depending on the various build jobs.
      The variables can be set from the trigger job in a project's
      `.gitlab-ci.yml` file. They are eval'ed before saving them to
      version.env, so we can use deferred variable expansion or even command
      execution to construct their values. This mechanism is already used for
      the Flash-N-Go System variables.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@073ae81e
      
      LAVA: rename MACHINE to LAVA_MACHINE
      
      Rename variable in order to avoid confusion with the original MACHINE
      variable used everywhere else. Also rename the local Jinja2 variable to
      include an underscore to make naming consistent.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@a91baa55
      
      Clean build.env before writing
      
      This had been accidentally removed in
      5e36715ef6cf98df4c1b98fedddc0c3c50ed4040.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@1860ca8e
      
      Remove LOG_PREFIX variable
      
      This was used in times when the same code was executed from different
      places. We don't do that anymore, so the variable is obsolete.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@3d2dbe4d
      
      Documentation: update job generation chapter
      efe5891a
  6. Sep 04, 2023
  7. Aug 30, 2023
  8. Aug 28, 2023
  9. Aug 24, 2023
    • GitBot's avatar
      Integrate gitlab-ci/add-azure-stage · 47e23142
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@e6808701
      
      Add "Deploy Azure" stage
      
      This stage contains jobs to deploy packaged artifacts to our Azure blob
      storage. The required variables `AZURE_STORAGE_ACCOUNT` and
      `AZURE_STORAGE_SAS_TOKEN` are stored in the GitLab CI/CD variables.
      The storage container `AZURE_CONTAINER_NAME` and artifact path
      `AZURE_TARGET_FOLDER` are passed from the parent pipeline.
      47e23142
  10. Aug 22, 2023
    • GitBot's avatar
      Integrate gitlab-ci/add-confluence-stage and 2 more · b064aeb7
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@f8c1d732
      
      Add confluence stage
      
      This adds two jobs to the Yocto pipeline:
      
       - generate-confluence-page
       - publish-confluence-page
      
      The first one generates a confluence page from a template
      (`confluence-page.xml.jinja2`) using information downloaded from all
      successful "Deploy FTP" jobs of the same pipeline.
      
      The second one publishes this page in Confluence and displays a link to
      the new page. If the page already exists it is overwritten.
      
      The place in Confluence where the new page is published is configurable
      via the `CONFLUENCE_SPACE` and `CONFLUENCE_PARENT_ID` variables.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@fee9493b
      
      generate-build-pipeline: re-add YAML format parsing
      
      This was accidentally forgotten in the previous commit.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@9b777f29
      
      Rename "generate_job_from_template" script to "render_jinja2_template"
      
      This makes the script more general and open for other future purposes.
      The parsing of the YAML content is conditional now, depending on the new
      "format" argument.
      b064aeb7
  11. Aug 11, 2023
  12. Jul 27, 2023
    • GitBot's avatar
      Integrate gitlab-ci/separate-images-in-multiple-pipelines and 1 more · cdbd5b71
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@9406ad75
      
      Yocto build: separate images in multiple pipelines
      
      Instead of building the Yocto image, the Yocto SDK and the FNGSystem
      image in one single pipeline, separate them into three independent
      pipelines that are triggered in parallel.
      
      This makes the concept more modular: we have a single general pipeline
      now which is configurable from outside via variables. Hence we can have
      a custom number of pipelines along with custom build targets in each
      project without having to make code changes in the gitlab-ci project.
      
      The default Yocto manifest pipeline configures three build pipelines:
      
      - yocto-build-jobs
      - sdk-build-jobs
      - fngsystem-build-jobs
      
      In a project including the Yocto manifest pipeline, we can disable
      certain build pipelines using job rules, e.g. disabling the SDK build:
      
      sdk-build-jobs:
        rules:
          - when: never
      
      Furthermore we can add more pipelines by simply adding jobs extending
      the '.build-jobs' class in the project's .gitlab-ci.yml:
      
      yocto-custom-build-jobs:
        extends:
          - .build-jobs
        variables:
          BITBAKE_TASK: build
          CI_PARAM_IMAGE: custom-image
          CI_PARAM_DISTRO: custom-distro
          PACKAGE_TYPE: image
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@447804d2
      
      .gitlab-ci: increase analyze timeout
      cdbd5b71
  13. Jul 25, 2023
    • GitBot's avatar
      Integrate gitlab-ci/unify-image-and-sdk-package-jobs and 3 more · bedc0417
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@5762a54c
      
      Yocto build: unify image and SDK package jobs
      
      Image and SDK package jobs call the same package script just with
      different arguments. Instead of having two job classes `package_release`
      and `package_sdk` for these two tasks, merge them into the base class
      `package` and make the differences configurable via a variable
      `PACKAGE_TYPE`.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@8e72eac2
      
      Yocto build: add variable for manual builds
      
      Instead of hard-coding the rules for manual builds in each actual job,
      conditionally add this to the `buildbase` class and add a variable
      `MANUAL_BUILD` to the according jobs.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@e6d71996
      
      Yocto build: unify image and SDK build jobs
      
      Image and SDK builds share a lot of similar code. Instead of having two
      job classes `build_yocto_image` and `build_yocto_sdk` for these two
      tasks, merge them into the base class `build_yocto` and make the
      differences configurable via a variable.
      
      The `dump_install_command` part of the script, which was not executed
      for SDK builds, is always present now, but it's only executed if the
      `INSTALLSCRIPT` variable is set, which is not the case for SDK builds.
      
      The `collect_srcrevs` part of the script is executed in all cases. It
      was not part of the SDK build before, but it's not less relevant there.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@f892500f
      
      Yocto build: make main artifacts path configurable
      
      Instead of specifying all possible artifacts paths and abusing the fact
      that GitLab ignores non-existing paths during artifact upload, implement
      a cleaner solution with a configurable path.
      bedc0417
  14. Jul 24, 2023
  15. Jul 11, 2023
  16. Jul 07, 2023
  17. Jun 02, 2023
  18. May 15, 2023
  19. May 12, 2023
  20. May 10, 2023
  21. Apr 24, 2023
  22. Apr 04, 2023
    • GitBot's avatar
      Integrate gitlab-ci/depend-pipeline-execution-on-branch-protection-state and 2 more · 92520330
      GitBot authored and Tim Jaacks's avatar Tim Jaacks committed
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@939ade2b
      
      Depend intgration pipeline execution on branch protection state
      
      Previously we had the master branch hard-coded in a variable in order to
      determine whether to run the integration pipeline (on non-master branch)
      or the merge pipeline (on master branch). This variable had to be
      adapted everytime we copy a branch, which can potentially be forgotten
      and lead to problems.
      
      Remove the hard-coded branch and use the branch protection state for
      this decision instead in order to make this more flexible.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@dbc49ad0
      
      Simplify yamllint job rules
      
      The rules for the yamllint jobs have been defined in the .yamllint class
      before. They were overridden in the manifest pipeline's yamllint job,
      though, which has its own rules, so we don't need them to be inherited
      in this case. And in the manifest integration pipeline the rules can be
      much easier, so define them there instead of at the class-level.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@cd8de4ff
      
      .gitlab-ci: add analyze stage for limiting YAML script blocks
      92520330
  23. Apr 03, 2023
  24. Mar 21, 2023
  25. Mar 20, 2023
  26. Mar 09, 2023
  27. Mar 02, 2023
  28. Feb 28, 2023
  29. Feb 23, 2023
    • Francesco Dolcini's avatar
      net: phy: Fix race condition on link status change · 7ea8259a
      Francesco Dolcini authored and Dmitry Petrov's avatar Dmitry Petrov committed
      commit 91a7cda1f4b8bdf770000a3b60640576dafe0cec upstream.
      
      This fixes the following error caused by a race condition between
      phydev->adjust_link() and a MDIO transaction in the phy interrupt
      handler. The issue was reproduced with the ethernet FEC driver and a
      micrel KSZ9031 phy.
      
      [  146.195696] fec 2188000.ethernet eth0: MDIO read timeout
      [  146.201779] ------------[ cut here ]------------
      [  146.206671] WARNING: CPU: 0 PID: 571 at drivers/net/phy/phy.c:942 phy_error+0x24/0x6c
      [  146.214744] Modules linked in: bnep imx_vdoa imx_sdma evbug
      [  146.220640] CPU: 0 PID: 571 Comm: irq/128-2188000 Not tainted 5.18.0-rc3-00080-gd569e86915b7 #9
      [  146.229563] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      [  146.236257]  unwind_backtrace from show_stack+0x10/0x14
      [  146.241640]  show_stack from dump_stack_lvl+0x58/0x70
      [  146.246841]  dump_stack_lvl from __warn+0xb4/0x24c
      [  146.251772]  __warn from warn_slowpath_fmt+0x5c/0xd4
      [  146.256873]  warn_slowpath_fmt from phy_error+0x24/0x6c
      [  146.262249]  phy_error from kszphy_handle_interrupt+0x40/0x48
      [  146.268159]  kszphy_handle_interrupt from irq_thread_fn+0x1c/0x78
      [  146.274417]  irq_thread_fn from irq_thread+0xf0/0x1dc
      [  146.279605]  irq_thread from kthread+0xe4/0x104
      [  146.284267]  kthread from ret_from_fork+0x14/0x28
      [  146.289164] Exception stack(0xe6fa1fb0 to 0xe6fa1ff8)
      [  146.294448] 1fa0:                                     00000000 00000000 00000000 00000000
      [  146.302842] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [  146.311281] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
      [  146.318262] irq event stamp: 12325
      [  146.321780] hardirqs last  enabled at (12333): [<c01984c4>] __up_console_sem+0x50/0x60
      [  146.330013] hardirqs last disabled at (12342): [<c01984b0>] __up_console_sem+0x3c/0x60
      [  146.338259] softirqs last  enabled at (12324): [<c01017f0>] __do_softirq+0x2c0/0x624
      [  146.346311] softirqs last disabled at (12319): [<c01300ac>] __irq_exit_rcu+0x138/0x178
      [  146.354447] ---[ end trace 0000000000000000 ]---
      
      With the FEC driver phydev->adjust_link() calls fec_enet_adjust_link()
      calls fec_stop()/fec_restart() and both these function reset and
      temporary disable the FEC disrupting any MII transaction that
      could be happening at the same time.
      
      fec_enet_adjust_link() and phy_read() can be running at the same time
      when we have one additional interrupt before the phy_state_machine() is
      able to terminate.
      
      Thread 1 (phylib WQ)       | Thread 2 (phy interrupt)
                                 |
                                 | phy_interrupt()            <-- PHY IRQ
                                 |  handle_interrupt()
                                 |   phy_read()
                                 |   phy_trigger_machine()
                                 |    --> schedule phylib WQ
                                 |
                                 |
      phy_state_machine()        |
       phy_check_link_status()   |
        phy_link_change()        |
         phydev->adjust_link()   |
          fec_enet_adjust_link() |
           --> FEC reset         | phy_interrupt()            <-- PHY IRQ
                                 |  phy_read()
                                 |
      
      Fix this by acquiring the phydev lock in phy_interrupt().
      
      Link: https://lore.kernel.org/all/20220422152612.GA510015@francesco-nb.int.toradex.com/
      
      
      Fixes: c974bdbc ("net: phy: Use threaded IRQ, to allow IRQ from sleeping devices")
      cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarFrancesco Dolcini <francesco.dolcini@toradex.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20220506060815.327382-1-francesco.dolcini@toradex.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ea8259a
  30. Feb 20, 2023
  31. Feb 10, 2023
  32. Feb 08, 2023
    • Dmitry Petrov's avatar
      regulator: pfuze100: Fix shutdown callback · ccb606a2
      Dmitry Petrov authored
      
      During testing of shutdown feature on SantVend board it was discovered
      that in some cases (one out of five):
      - a board turns off immediately after a power-off gpio is asserted (and
        not after 4 seconds);
      - but after 4 seconds, the board turns on again.
      
      The problem appears only when edge triggering mode has been configured in
      shutdown callback - see "regulator: pfuze100: Implement an off state"
      
      After experimenting it has been found that the issue cannot be
      reproduced when:
      - the edge triggered mode is configured in the driver at boot time (and
        not in shutdown callback);
      - the edge triggered mode is configured after boot in userspace via
        i2cset commands (and not in shutdown callback);
      - a huge delay (about 15sec) is added after setting the edge triggered
        mode in shutdown callback;
      - a small delay (10ms) is added after each regmap_write call during
        setting the edge triggered mode in shutdown callback.
      
      It looks like PMIC needs some time to apply the changes performed via
      regmap_write() calls when the edge triggered mode is activated. And if
      regmap_write() calls are issued without delays, the PMIC gets fail to
      process them, despite the fact that proper values can be read back from
      registers.
      
      So, the commit adds small delays between i2c commands to work around this
      issue.
      
      Signed-off-by: default avatarDmitry Petrov <dmitry.petrov@rtsoft.de>
      ccb606a2
    • Dmitry Petrov's avatar
      regulator: pfuze100: Add support of SYSTEM_SCHEDULING state · 54054cda
      Dmitry Petrov authored
      
      After switching to 5.15 kernel, PMIC setting are not restored properly
      after boot. The problem is casued by new system state, which was added
      in 'commit 69a78ff2 ("init: Introduce SYSTEM_SCHEDULING state")'
      
      Update "pfuze100_reset_factory_defaults" function to take this new state
      into account.
      
      Signed-off-by: default avatarDmitry Petrov <dmitry.petrov@rtsoft.de>
      54054cda
    • Dmitry Petrov's avatar
      dt-bindings: pfuze100: Add optional poweroff-capable · ed1f769b
      Dmitry Petrov authored
      
      Document an optional property "poweroff-capable" for the
      PFUZE100 driver.
      
      Signed-off-by: default avatarDmitry Petrov <dmitry.petrov@rtsoft.de>
      ed1f769b
Loading