Message ID | 20170202020607.31682-1-f.fainelli@gmail.com |
---|---|
State | New |
Headers | show |
On Wednesday, February 1, 2017 6:06:07 PM CET Florian Fainelli wrote: > Please note that because of the "clk" topic branch merged by Eric, we end-up with > pulling in v4.10-rc2 which is responsible for the funny diff here. It's generally better to avoid those back-merges entirely, that is not the only problem with them. Our DT branch is already based on -rc3, so it's not a back-merged for me, and I think that's ok when I send it upstream. However, I see that you do pull in these changes: Eric Anholt (5): clk: bcm2835: Don't rate change PLLs on behalf of DSI PLL dividers. clk: bcm2835: Register the DSI0/DSI1 pixel clocks. clk: bcm2835: Add leaf clock measurement support, disabled by default I'd rather not have those in next/dt at all, and at the very least we require an explanation in the changelog about why you are sending them to arm-soc. I assume that they are present in the clk-next tree and won't get rebased, but that's not clear from your pull request. Are you doing an incompatible DT binding change that requires changing the dts files and the driver together? If so, that also needs to be in the changelog (or avoided if at all possible). If you send the other changes again today, I'll pull them right away, and then we can talk about what we do for the clk-bcm2835 changes. Arnd
On 02/07/2017 06:49 AM, Arnd Bergmann wrote: > On Wednesday, February 1, 2017 6:06:07 PM CET Florian Fainelli wrote: >> Please note that because of the "clk" topic branch merged by Eric, we end-up with >> pulling in v4.10-rc2 which is responsible for the funny diff here. > > It's generally better to avoid those back-merges entirely, that is not > the only problem with them. Our DT branch is already based on -rc3, > so it's not a back-merged for me, and I think that's ok when I send > it upstream. > > However, I see that you do pull in these changes: > > Eric Anholt (5): > clk: bcm2835: Don't rate change PLLs on behalf of DSI PLL dividers. > clk: bcm2835: Register the DSI0/DSI1 pixel clocks. > clk: bcm2835: Add leaf clock measurement support, disabled by default > > I'd rather not have those in next/dt at all, and at the very least > we require an explanation in the changelog about why you are sending > them to arm-soc. I assume that they are present in the clk-next > tree and won't get rebased, but that's not clear from your pull > request. OK, the explanation is provided in the merge commit, but I suppose I should have added this again to the pull request changelog. > > Are you doing an incompatible DT binding change that requires changing > the dts files and the driver together? If so, that also needs to be > in the changelog (or avoided if at all possible). Eric, do you mind commenting on that part? > > If you send the other changes again today, I'll pull them right away, > and then we can talk about what we do for the clk-bcm2835 changes. OK, let me try to sync up with Eric on this and see if we can come up with something better. A pull request based on v4.10-rc3 would be acceptable, right?
Arnd Bergmann <arnd@arndb.de> writes: > On Wednesday, February 1, 2017 6:06:07 PM CET Florian Fainelli wrote: >> Please note that because of the "clk" topic branch merged by Eric, we end-up with >> pulling in v4.10-rc2 which is responsible for the funny diff here. > > It's generally better to avoid those back-merges entirely, that is not > the only problem with them. Our DT branch is already based on -rc3, > so it's not a back-merged for me, and I think that's ok when I send > it upstream. > > However, I see that you do pull in these changes: > > Eric Anholt (5): > clk: bcm2835: Don't rate change PLLs on behalf of DSI PLL dividers. > clk: bcm2835: Register the DSI0/DSI1 pixel clocks. > clk: bcm2835: Add leaf clock measurement support, disabled by default > > I'd rather not have those in next/dt at all, and at the very least > we require an explanation in the changelog about why you are sending > them to arm-soc. I assume that they are present in the clk-next > tree and won't get rebased, but that's not clear from your pull > request. > > Are you doing an incompatible DT binding change that requires changing > the dts files and the driver together? If so, that also needs to be > in the changelog (or avoided if at all possible). The clock maintainers merged my patches that created a new index in the DT binding, and produced a clk-bcm2835 branch for us to merge so that we could get the new index #defines. I guess I wasn't clear in my PR (https://lkml.org/lkml/2017/1/31/736) that the reason for the merge was just that we needed the #define. I'll try to be better about that.
On Tue, Feb 7, 2017 at 9:59 PM, Florian Fainelli <f.fainelli@gmail.com> wrote: > On 02/07/2017 06:49 AM, Arnd Bergmann wrote: >> On Wednesday, February 1, 2017 6:06:07 PM CET Florian Fainelli wrote: >>> Please note that because of the "clk" topic branch merged by Eric, we end-up with >>> pulling in v4.10-rc2 which is responsible for the funny diff here. >> >> It's generally better to avoid those back-merges entirely, that is not >> the only problem with them. Our DT branch is already based on -rc3, >> so it's not a back-merged for me, and I think that's ok when I send >> it upstream. >> >> However, I see that you do pull in these changes: >> >> Eric Anholt (5): >> clk: bcm2835: Don't rate change PLLs on behalf of DSI PLL dividers. >> clk: bcm2835: Register the DSI0/DSI1 pixel clocks. >> clk: bcm2835: Add leaf clock measurement support, disabled by default >> >> I'd rather not have those in next/dt at all, and at the very least >> we require an explanation in the changelog about why you are sending >> them to arm-soc. I assume that they are present in the clk-next >> tree and won't get rebased, but that's not clear from your pull >> request. > > OK, the explanation is provided in the merge commit, but I suppose I > should have added this again to the pull request changelog. Yes, more generally speaking, the pull request changelog (i.e. the tag description) should give me enough information to decide whether to merge it or not. >> If you send the other changes again today, I'll pull them right away, >> and then we can talk about what we do for the clk-bcm2835 changes. > > OK, let me try to sync up with Eric on this and see if we can come up > with something better. A pull request based on v4.10-rc3 would be > acceptable, right? Yes, basing on -rc3 is fine. I think you pulled Eric's branch into yours last, so if you just send the pull request without that merge, and without rebasing, then we can take all other changes. For the bcm2835, try coming up with a branch that doesn't need the dependency and send that separately. There are three common ways to do that: - rebase the patches on top of the commit that introduced the header file change, provided that one sits directly on top of an -rc without any driver patches below it (or in the same patch) - change the dts files to refer to the clk by numeric value instead of the macro name, then follow up with a patch to use the name for a later release - defer the whole branch for the next kernel release. Arnd
Arnd Bergmann <arnd@arndb.de> writes: > On Tue, Feb 7, 2017 at 9:59 PM, Florian Fainelli <f.fainelli@gmail.com> wrote: >> On 02/07/2017 06:49 AM, Arnd Bergmann wrote: >>> On Wednesday, February 1, 2017 6:06:07 PM CET Florian Fainelli wrote: >>>> Please note that because of the "clk" topic branch merged by Eric, we end-up with >>>> pulling in v4.10-rc2 which is responsible for the funny diff here. >>> >>> It's generally better to avoid those back-merges entirely, that is not >>> the only problem with them. Our DT branch is already based on -rc3, >>> so it's not a back-merged for me, and I think that's ok when I send >>> it upstream. >>> >>> However, I see that you do pull in these changes: >>> >>> Eric Anholt (5): >>> clk: bcm2835: Don't rate change PLLs on behalf of DSI PLL dividers. >>> clk: bcm2835: Register the DSI0/DSI1 pixel clocks. >>> clk: bcm2835: Add leaf clock measurement support, disabled by default >>> >>> I'd rather not have those in next/dt at all, and at the very least >>> we require an explanation in the changelog about why you are sending >>> them to arm-soc. I assume that they are present in the clk-next >>> tree and won't get rebased, but that's not clear from your pull >>> request. >> >> OK, the explanation is provided in the merge commit, but I suppose I >> should have added this again to the pull request changelog. > > Yes, more generally speaking, the pull request changelog (i.e. the tag > description) should give me enough information to decide whether to > merge it or not. > >>> If you send the other changes again today, I'll pull them right away, >>> and then we can talk about what we do for the clk-bcm2835 changes. >> >> OK, let me try to sync up with Eric on this and see if we can come up >> with something better. A pull request based on v4.10-rc3 would be >> acceptable, right? > > Yes, basing on -rc3 is fine. I think you pulled Eric's branch into yours > last, so if you just send the pull request without that merge, and without > rebasing, then we can take all other changes. > > For the bcm2835, try coming up with a branch that doesn't need the > dependency and send that separately. There are three common ways > to do that: > > - rebase the patches on top of the commit that introduced the header file > change, provided that one sits directly on top of an -rc without any > driver patches below it (or in the same patch) > - change the dts files to refer to the clk by numeric value instead of the > macro name, then follow up with a patch to use the name for a later > release > - defer the whole branch for the next kernel release. OK, if we can't merge the topic branch, I'll just punt on this for the next release. From previous topic branch merges, I thought the rule was "it's OK as long as you have the subsystem maintainer's ack."
On Tuesday, February 7, 2017 3:52:43 PM CET Eric Anholt wrote: > Arnd Bergmann <arnd@arndb.de> writes: n we can take all other changes. > > > > For the bcm2835, try coming up with a branch that doesn't need the > > dependency and send that separately. There are three common ways > > to do that: > > > > - rebase the patches on top of the commit that introduced the header file > > change, provided that one sits directly on top of an -rc without any > > driver patches below it (or in the same patch) > > - change the dts files to refer to the clk by numeric value instead of the > > macro name, then follow up with a patch to use the name for a later > > release > > - defer the whole branch for the next kernel release. > > OK, if we can't merge the topic branch, I'll just punt on this for the > next release. From previous topic branch merges, I thought the rule was > "it's OK as long as you have the subsystem maintainer's ack." I should probably explain this a bit more: We never liked those dependencies but let them slip through in the past, as there isn't a lot of damage. For a while we had a 'next/late' branch in which we queued up changes that had dependencies on other branches, and then we sent that branch to Linus once the dependencies were all merged. This works, but it's always been annoying, so we try to avoid it completely now. The kernel releases are frequent enough that waiting for another merge window isn't a big deal if you plan for it in advance. Also, a lot of the header file dependencies are completely avoidable: In some cases not using a header leads to a better binding: e.g. most interrupt controllers just enumerate their IRQ lines so there is no ambiguity regarding which line has which number. For clk controllers this is often but not always the case, but often enough you at least know what clocks are present and can give them names without having to implement every single clk output setting in the clk controller. Arnd
On 02/08/2017 01:01 AM, Arnd Bergmann wrote: > On Tuesday, February 7, 2017 3:52:43 PM CET Eric Anholt wrote: >> Arnd Bergmann <arnd@arndb.de> writes: > > n we can take all other changes. I am going to hold off on sending the remainder of the changes because there is one particular changes that Rafal is not happy with. Thanks Arnd!
Hi Florian, ARM SoC maintainers, On Wed, Feb 01, 2017 at 06:06:07PM -0800, Florian Fainelli wrote: > The following changes since commit c5a8e3add28ca4063410353acfbe6e650174e432: > > Merge tag 'bcm2835-dt-next-2017-01-17' into devicetree/next (2017-01-18 17:20:32 -0800) > > are available in the git repository at: > > http://github.com/Broadcom/stblinux tags/arm-soc/for-4.11/devicetree-part2 > > for you to fetch changes up to c206e53d4c672ec83a4fc4d70eeac22d4b4ca80d: > > Merge tag 'bcm2835-dt-next-2017-01-31' into devicetree/next (2017-02-01 17:37:59 -0800) > > ---------------------------------------------------------------- > This pull request contains the second round of Device Tree updates for Broadcom > ARM-based SoCs for 4.11, please pull the following: > > - Rafal adds support for two new Linksys routers: Linksys EA9200 (BCM4709) and > Linksys EA6300 V1 (BCM4708) > > - Dhanajay adds supports for the USB Device Tree nodes to the Northstar Plus > SoC > > - Baruch makes several fixes to the uart0 pinctrl node names, fixes the i2c0 pins > and the uart0/uart1 pins as well. Finally, he adds proper indexes to the ethernet > aliases > > - Eric merges a topic branch from the clk tree to incorporate several DSI0/1 pixel > clock requirements and he finally proceeds with adding proper DSI modules nodes > and clocks to the BCM2835 Device Tree > > Please note that because of the "clk" topic branch merged by Eric, we end-up with > pulling in v4.10-rc2 which is responsible for the funny diff here. What happened to this pull request? v4.11-rc1 is out now. baruch > > ---------------------------------------------------------------- > Al Viro (1): > arm64: don't pull uaccess.h into *.S > > Baruch Siach (4): > ARM: dts: bcm2835: fix uart0 pinctrl node names > ARM: dts: bcm2835: fix i2c0 pins > ARM: dts: bcm2835: fix uart0/uart1 pins > ARM: dts: bcm2835: add index to the ethernet alias > > Chun-Hao Lin (1): > r8169: add support for RTL8168 series add-on card. > > Cihangir Akturk (1): > Documentation/unaligned-memory-access.txt: fix incorrect comparison operator > > Daniel Borkmann (1): > net, sched: fix soft lockup in tc_classify > > Eric Anholt (5): > clk: bcm2835: Don't rate change PLLs on behalf of DSI PLL dividers. > clk: bcm2835: Register the DSI0/DSI1 pixel clocks. > clk: bcm2835: Add leaf clock measurement support, disabled by default > Merge remote-tracking branch 'clk/clk-bcm2835' into bcm2835-dt-next > ARM: dts: bcm2835: Add the DSI module nodes and clocks. > > Eric Dumazet (1): > ipvlan: fix various issues in ipvlan_process_multicast() > > Florian Fainelli (2): > net: korina: Fix NAPI versus resources freeing > Merge tag 'bcm2835-dt-next-2017-01-31' into devicetree/next > > Haishuang Yan (1): > ipv4: Namespaceify tcp_tw_reuse knob > > Jan Kara (6): > ext2: Return BH_New buffers for zeroed blocks > mm: Invalidate DAX radix tree entries only if appropriate > dax: Avoid page invalidation races and unnecessary radix tree traversals > dax: Finish fault completely when loading holes > dax: Call ->iomap_begin without entry lock during dax fault > ext4: Simplify DAX fault path > > Jason Wang (1): > net: xdp: remove unused bfp_warn_invalid_xdp_buffer() > > John Brooks (1): > docs: Fix build failure > > Jon Paul Maloy (1): > tipc: don't send FIN message from connectionless socket > > Jonathan Corbet (1): > Merge tag 'v4.10-rc1' into docs-next > > Kweh, Hock Leong (1): > net: stmmac: fix incorrect bit set in gmac4 mdio addr register > > Laura Abbott (1): > crypto: testmgr - Use heap buffer for acomp test input > > Linus Torvalds (7): > Merge git://git.kernel.org/.../davem/net > Merge branch 'linus' of git://git.kernel.org/.../herbert/crypto-2.6 > mm: optimize PageWaiters bit use for unlock_page() > Merge branch 'linus' of git://git.kernel.org/.../herbert/crypto-2.6 > Merge tag 'docs-4.10-rc1-fix' of git://git.lwn.net/linux > Merge branch 'libnvdimm-fixes' of git://git.kernel.org/.../nvdimm/nvdimm > Linux 4.10-rc2 > > Mahesh Bandewar (1): > ipvlan: fix multicast processing > > Olof Johansson (1): > mm/filemap: fix parameters to test_bit() > > Rafał Miłecki (2): > ARM: dts: BCM5301X: Add basic DT for Linksys EA9200 > ARM: dts: BCM5301X: Add basic DT for Linksys EA6300 V1 > > Romain Perier (1): > crypto: marvell - Copy IVDIG before launching partial DMA ahash requests > > Tariq Toukan (1): > net/mlx4_en: Fix user prio field in XDP forward > > Thomas Gleixner (2): > smp/hotplug: Undo tglxs brainfart > x86/mce/AMD: Make the init code more robust > > Yendapally Reddy Dhananjaya Reddy (1): > ARM: dts: NSP: Add USB nodes for Northstar Plus > > pravin shelar (1): > openvswitch: upcall: Fix vlan handling. > > Documentation/DocBook/Makefile | 2 +- > .../bindings/clock/brcm,bcm2835-cprman.txt | 15 +- > Documentation/unaligned-memory-access.txt | 2 +- > Makefile | 2 +- > arch/arm/boot/dts/Makefile | 2 + > arch/arm/boot/dts/bcm-nsp.dtsi | 56 ++++ > arch/arm/boot/dts/bcm2835-rpi.dtsi | 8 + > arch/arm/boot/dts/bcm283x-rpi-smsc9512.dtsi | 2 +- > arch/arm/boot/dts/bcm283x-rpi-smsc9514.dtsi | 2 +- > arch/arm/boot/dts/bcm283x.dtsi | 70 ++++- > arch/arm/boot/dts/bcm4708-linksys-ea6300-v1.dts | 41 +++ > arch/arm/boot/dts/bcm4709-linksys-ea9200.dts | 42 +++ > arch/arm/boot/dts/bcm958625k.dts | 16 ++ > arch/arm64/include/asm/asm-uaccess.h | 65 +++++ > arch/arm64/include/asm/uaccess.h | 64 ----- > arch/arm64/kernel/entry.S | 2 +- > arch/arm64/lib/clear_user.S | 2 +- > arch/arm64/lib/copy_from_user.S | 2 +- > arch/arm64/lib/copy_in_user.S | 2 +- > arch/arm64/lib/copy_to_user.S | 2 +- > arch/arm64/mm/cache.S | 2 +- > arch/arm64/xen/hypercall.S | 2 +- > arch/x86/include/asm/bitops.h | 13 + > arch/x86/kernel/cpu/mcheck/mce_amd.c | 3 + > crypto/testmgr.c | 30 +- > drivers/clk/bcm/clk-bcm2835.c | 303 +++++++++++++++++---- > drivers/crypto/marvell/cesa.h | 3 +- > drivers/crypto/marvell/hash.c | 34 ++- > drivers/crypto/marvell/tdma.c | 9 +- > drivers/net/ethernet/korina.c | 8 +- > drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 3 +- > drivers/net/ethernet/realtek/r8169.c | 1 + > drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 4 +- > drivers/net/ipvlan/ipvlan.h | 5 + > drivers/net/ipvlan/ipvlan_core.c | 60 ++-- > drivers/net/ipvlan/ipvlan_main.c | 7 +- > fs/dax.c | 243 +++++++++++------ > fs/ext2/inode.c | 3 +- > fs/ext4/file.c | 48 +--- > include/dt-bindings/clock/bcm2835.h | 2 + > include/linux/dax.h | 3 + > include/linux/filter.h | 1 - > include/linux/page-flags.h | 2 +- > include/net/netns/ipv4.h | 1 + > include/net/tcp.h | 1 - > kernel/cpu.c | 9 +- > mm/filemap.c | 36 ++- > mm/truncate.c | 75 ++++- > net/core/filter.c | 6 - > net/ipv4/sysctl_net_ipv4.c | 14 +- > net/ipv4/tcp_ipv4.c | 4 +- > net/openvswitch/datapath.c | 1 - > net/openvswitch/flow.c | 54 ++-- > net/sched/cls_api.c | 4 +- > net/tipc/socket.c | 24 +- > 55 files changed, 1038 insertions(+), 379 deletions(-) > create mode 100644 arch/arm/boot/dts/bcm4708-linksys-ea6300-v1.dts > create mode 100644 arch/arm/boot/dts/bcm4709-linksys-ea9200.dts > create mode 100644 arch/arm64/include/asm/asm-uaccess.h
On 03/05/2017 08:29 PM, Baruch Siach wrote: > Hi Florian, ARM SoC maintainers, > > On Wed, Feb 01, 2017 at 06:06:07PM -0800, Florian Fainelli wrote: >> The following changes since commit c5a8e3add28ca4063410353acfbe6e650174e432: >> >> Merge tag 'bcm2835-dt-next-2017-01-17' into devicetree/next (2017-01-18 17:20:32 -0800) >> >> are available in the git repository at: >> >> http://github.com/Broadcom/stblinux tags/arm-soc/for-4.11/devicetree-part2 >> >> for you to fetch changes up to c206e53d4c672ec83a4fc4d70eeac22d4b4ca80d: >> >> Merge tag 'bcm2835-dt-next-2017-01-31' into devicetree/next (2017-02-01 17:37:59 -0800) >> >> ---------------------------------------------------------------- >> This pull request contains the second round of Device Tree updates for Broadcom >> ARM-based SoCs for 4.11, please pull the following: >> >> - Rafal adds support for two new Linksys routers: Linksys EA9200 (BCM4709) and >> Linksys EA6300 V1 (BCM4708) >> >> - Dhanajay adds supports for the USB Device Tree nodes to the Northstar Plus >> SoC >> >> - Baruch makes several fixes to the uart0 pinctrl node names, fixes the i2c0 pins >> and the uart0/uart1 pins as well. Finally, he adds proper indexes to the ethernet >> aliases >> >> - Eric merges a topic branch from the clk tree to incorporate several DSI0/1 pixel >> clock requirements and he finally proceeds with adding proper DSI modules nodes >> and clocks to the BCM2835 Device Tree >> >> Please note that because of the "clk" topic branch merged by Eric, we end-up with >> pulling in v4.10-rc2 which is responsible for the funny diff here. > > What happened to this pull request? v4.11-rc1 is out now. It was submitted too late, and therefore got postponed, so everything that's in there should show up for 4.12 now once Eric re-submits the BCM283x pull request in a few days.