Message ID | 20190819190552.11254-2-f.fainelli@gmail.com |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL,1/3] Broadcom defconfig changes for 5.4 | expand |
On Mon, Aug 19, 2019 at 9:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > > The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: > > Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) > > are available in the Git repository at: > > https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.4/defconfig-arm64 > > for you to fetch changes up to d6cc9ddd23f8b113797152896462b27e2b213ece: > > Merge tag 'tags/bcm2835-defconfig-64-next-2019-08-15' into defconfig-arm64/next (2019-08-15 11:38:29 -0700) > > ---------------------------------------------------------------- > This pull request contains Broadcom ARM64-based SoCs defconfig updates > for 5.4, please pull the following: > > - Nicolas enables the Raspberry Pi CPUFREQ driver in the ARM64 defconfig file Pulled into arm/defconfig. The way we work at the moment, there is no real need to split changes to the arm32 and arm64 defconfig files into separate pull requests or even separate patches. Since this is the same change as the previous pull request, having a single patch to enable cpufreq everywhere would have been easier. Arnd
Hi Arnd, Am 04.09.19 um 15:02 schrieb Arnd Bergmann: > On Mon, Aug 19, 2019 at 9:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote: >> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: >> >> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) >> >> are available in the Git repository at: >> >> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.4/defconfig-arm64 >> >> for you to fetch changes up to d6cc9ddd23f8b113797152896462b27e2b213ece: >> >> Merge tag 'tags/bcm2835-defconfig-64-next-2019-08-15' into defconfig-arm64/next (2019-08-15 11:38:29 -0700) >> >> ---------------------------------------------------------------- >> This pull request contains Broadcom ARM64-based SoCs defconfig updates >> for 5.4, please pull the following: >> >> - Nicolas enables the Raspberry Pi CPUFREQ driver in the ARM64 defconfig file > Pulled into arm/defconfig. > > The way we work at the moment, there is no real need to split changes > to the arm32 and arm64 defconfig files into separate pull requests or even > separate patches. this is new to me. My understanding was to separate all changes between arm32 and arm64 changes. So this isn't necessary for the DT arm/arm64 changes, too? > Since this is the same change as the previous pull > request, having a single patch to enable cpufreq everywhere would have > been easier. > > Arnd
On Wed, Sep 4, 2019 at 7:06 PM Stefan Wahren <wahrenst@gmx.net> wrote: > Am 04.09.19 um 15:02 schrieb Arnd Bergmann: > > On Mon, Aug 19, 2019 at 9:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > >> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: > >> > >> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) > >> > >> are available in the Git repository at: > >> > >> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.4/defconfig-arm64 > >> > >> for you to fetch changes up to d6cc9ddd23f8b113797152896462b27e2b213ece: > >> > >> Merge tag 'tags/bcm2835-defconfig-64-next-2019-08-15' into defconfig-arm64/next (2019-08-15 11:38:29 -0700) > >> > >> ---------------------------------------------------------------- > >> This pull request contains Broadcom ARM64-based SoCs defconfig updates > >> for 5.4, please pull the following: > >> > >> - Nicolas enables the Raspberry Pi CPUFREQ driver in the ARM64 defconfig file > > Pulled into arm/defconfig. > > > > The way we work at the moment, there is no real need to split changes > > to the arm32 and arm64 defconfig files into separate pull requests or even > > separate patches. > > this is new to me. My understanding was to separate all changes between > arm32 and arm64 changes. Right, that was the policy for a long time, but it has gradually gotten more relaxed. > So this isn't necessary for the DT arm/arm64 changes, too? I would still like to see large pull requests get split up into logical chunks, and the 32/64 split tends to be a natural boundary for many things, but I think there are cases where it makes more sense to combine. For instance, the raspberry pi changes tend to go together for 32/64, so a single pull request is best here. OTOH, if there are many changes for one Broadcom platform, in addition to a couple of patches each for the other platforms, a good split might be a) bcm283{5678}, both 32-bit and 64-bit combined b) random other 32-bit DT changes c) random other 64-bit DT changes As a rule of thumb, the best pull requests are those that clearly tell what goes on in the branch using a tag/commit description in a couple of paragraphs without enumerating unrelated items. (same as a changeset commit message actually). The branches we currently have are arm/fixes arm/defconfig arm/drivers arm/dt arm/soc arm/late Each of them contain 32-bit and 64-bit changes across all platforms. Arnd