| Message ID | 1348868177-21205-6-git-send-email-arnd@arndb.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Arnd Bergmann <arnd@arndb.de> writes: > Krzysztof, please apply in your next branch so this problem goes away in > 3.8. Right, I'll look at it. > I realize it won't make 3.7 any more since the base patches are not > in arm-soc, but it's bad if linux-next is broken. Well, I'm not aware of any requirement to push my IXP4xx changes exclusively through arm-soc. I believe I can still send my tree straight to Linus. My tree is fairly isolated (with one trivial patch in need of ack from Russell, but I can remove that) and, to be honest, I can't see any benefit to anyone, caused by sending through intermediate trees. In fact, now that I have at last a bit of spare time to work on IXP4xx again (acquired some IXP435 devices), such requirement would only mean extra workload to me. Could you please point me to a statement requiring eg. my changes to go through arm-soc? Thanks.
On Saturday 29 September 2012, Krzysztof Halasa wrote: > > I realize it won't make 3.7 any more since the base patches are not > > in arm-soc, but it's bad if linux-next is broken. > > Well, I'm not aware of any requirement to push my IXP4xx changes > exclusively through arm-soc. I believe I can still send my tree straight > to Linus. No, we don't do that any more, all ARM related changes go either through arm-soc (for mach-* and plat-* as well as a few related bits) or through Russell's arm tree (for everything else). We can make exceptions for stuff that has interdependencies with other subsystems and can Ack patches if you want to have them included in another subsystem tree. > My tree is fairly isolated (with one trivial patch in need of ack from > Russell, but I can remove that) and, to be honest, I can't see any > benefit to anyone, caused by sending through intermediate trees. In > fact, now that I have at last a bit of spare time to work on IXP4xx > again (acquired some IXP435 devices), such requirement would only mean > extra workload to me. > > Could you please point me to a statement requiring eg. my changes to go > through arm-soc? We've been doing it like this for some time. Stephen Warren replied to your request to add your tree to linux-next in http://comments.gmane.org/gmane.linux.kernel/1356118 explaining how it works. Olof sent a mail last week in http://lkml.org/lkml/2012/9/21/31 explaining that we're closing the window for 3.7 except for a few things that were already submitted earlier. You are definitely welcome to send your pull request for arm-soc after the merge window so we can integrate it into the 3.8 series, and please send any bug fixes you have for immediate integration at any time to arm@kernel.org. There may be a few other things in the process that are new to you, but we can work that out. The arm-soc process is definitely meant to make your life easier as well as help Linus understand what's going on with all of ARM to the degree that he needs to know, but it only works if everyone participates. Arnd
Arnd Bergmann <arnd@arndb.de> writes: >> Could you please point me to a statement requiring eg. my changes to go >> through arm-soc? > > We've been doing it like this for some time. Stephen Warren replied > to your request to add your tree to linux-next in > > http://comments.gmane.org/gmane.linux.kernel/1356118 > > explaining how it works. Olof sent a mail last week in > > http://lkml.org/lkml/2012/9/21/31 > > explaining that we're closing the window for 3.7 except for a > few things that were already submitted earlier. No offense, but... You say how does it work for YOU but that's not exactly what I'm asking for. I'm asking for a statement that it's not OK for me to push my IXP4xx changes straight to Linus. > The arm-soc process is definitely meant to make your life easier > as well as help Linus understand what's going on with all of ARM > to the degree that he needs to know, but it only works if everyone > participates. I'd like to know how is it easier for me. Actually, I think it would only make things worse for everyone (mostly for me). Also, I can't see how "it only works if everyone participates" is true. I'm currently supporting (for our internal needs) hw platforms based on x86, MIPS and now ARM. I'm using 3.1 (non-trivial upgrades required so -ETIME) and 3.5 "stable" trees, and need to also use Linus' current tree since it's the next stable. The hw is e.g. Gateworks' platforms with code taken from e.g. OpenWRT. I hope to have most of this in Linus' tree when it's eventually ready. Unfortunately, I'm just one man, and the above is only a slim part of my work. Egoistically, I don't think I'm currently willing to spend time with arm-soc tree, if I can't see any real technical benefit to anyone. It would be different if my tree included e.g. core ARM changes - but it doesn't. What's the _real_ reason for asking me to push my changes indirectly? Also, not that it's the most important, but how is it better for anyone to delay changes - which are completely orthogonal to arm-soc - for additional months? Doesn't "release early, release often" make sense anymore?
On Sat, Sep 29, 2012 at 10:02 AM, Krzysztof Halasa <khc@pm.waw.pl> wrote: > It would be different if my tree included e.g. core ARM changes - but it > doesn't. What's the _real_ reason for asking me to push my changes > indirectly? The reason is that when all ARM platform maintainers pushed code straight to Linus, no one was making sure that the code meets a quality bar and each vendor only focused on just their own stuff. As an end result, over the years lots of crap got pushed straight to Linus, code that we have now spent about a year and a half doing massive cleanups and restructurings of. No vendors really talked to each other, all of them solved their own problems their own way without figuring out how to work better together and build infrastructure for their common requirements. Linus finally lost his patience with the massive churn of duplicated reinvented code and there was a huge blow up about it. See http://lwn.net/Articles/439326/ for background. > Also, not that it's the most important, but how is it better for anyone > to delay changes - which are completely orthogonal to arm-soc - for > additional months? Doesn't "release early, release often" make sense > anymore? Nothing is delayed by going through arm-soc. We're closing down our tree for new (large) pull requests around the same time where you should no longer add them to your -next branch either (-rc6/-rc7 time frame). Small fixups, and of course bugfixes, are welcome closer to the merge window but the major chances should all have landed by then. -Olof
On Sat, Sep 29, 2012 at 07:02:36PM +0200, Krzysztof Halasa wrote: > Arnd Bergmann <arnd@arndb.de> writes: > > explaining that we're closing the window for 3.7 except for a > > few things that were already submitted earlier. > > No offense, but... You say how does it work for YOU but that's not > exactly what I'm asking for. I'm asking for a statement that it's > not OK for me to push my IXP4xx changes straight to Linus. If you bypass arm-soc, then you may find you have more problems - if the arm-soc goes in before you, and your tree conflicts with arm-soc. There are major changes going through at the present time which could very well mean that you miss something and IXP4xx gets broken because you're not participating. If you wish to find out about those breakages after the event, and play constant catch up, then pushing straight to Linus is what you should do. If you wish to know about the breakages, and fix them up ahead of time, then participate in the established process. > > The arm-soc process is definitely meant to make your life easier > > as well as help Linus understand what's going on with all of ARM > > to the degree that he needs to know, but it only works if everyone > > participates. > > I'd like to know how is it easier for me. Actually, I think it would > only make things worse for everyone (mostly for me). Also, I can't see > how "it only works if everyone participates" is true. > > I'm currently supporting (for our internal needs) hw platforms based > on x86, MIPS and now ARM. I'm using 3.1 (non-trivial upgrades required > so -ETIME) and 3.5 "stable" trees, and need to also use Linus' current > tree since it's the next stable. That makes no sense what so ever. The tree which is used for the next stable tree will be Linus' tree, which will be the result of merging all those other trees into Linus' tree. If you base your changes off only Linus' tree on the run up to the next merge window, then you are preparing your changes against an _older_ kernel than if you base them off a tree containing the changes which will be _included_ in the next merge window. So, in the long run, you'll end up doing the same amount of work, but you'll end up having to do the "fix it for the merge window" hoops _after_ your tree has been merged into mainline, rather than before. > Also, not that it's the most important, but how is it better for anyone > to delay changes - which are completely orthogonal to arm-soc - for > additional months? Doesn't "release early, release often" make sense > anymore? Err, no idea what you're getting at here, but take a moment to think about it. If you want to work in total isolation, that's your choice, but in the long run you will be playing catch-up rather than being prepared early for the changes which will happen at the next merge window. If you want -rc1, rc2, rc3, rc4 etc to be broken on IXP4xx until you get around to fixing up the merge window breakage, then go ahead. Otherwise, participate and be part of the community, and get your changes into arm-soc, so that others can see what's going on.
I realize my work flow is probably suboptimal, though I can't see an easy solution. Russell King - ARM Linux <linux@arm.linux.org.uk> writes: > That makes no sense what so ever. The tree which is used for the next > stable tree will be Linus' tree, which will be the result of merging all > those other trees into Linus' tree. If you base your changes off only > Linus' tree on the run up to the next merge window, then you are preparing > your changes against an _older_ kernel than if you base them off a tree > containing the changes which will be _included_ in the next merge > window. Yes. I have to fix my tree and ask for pull before the end of merge window (fixes could follow, but it's best when there are no fixes needed). I know it's not a great plan. Fortunately I'm not doing heavy, conflicting development on this. Note I'm not only doing ARM, but also X86 and MIPS, with additional code shared between them, and the "stable" part of it is what I'm paid for. I can't simply work with arm-soc, none of my platforms will even boot with pure arm-soc. > If you want to work in total isolation, that's your choice, but in the > long run you will be playing catch-up rather than being prepared early > for the changes which will happen at the next merge window. If you want > -rc1, rc2, rc3, rc4 etc to be broken on IXP4xx until you get around to > fixing up the merge window breakage, then go ahead. > > Otherwise, participate and be part of the community, and get your changes > into arm-soc, so that others can see what's going on. Unfortunately this seems to require more time on my part, time I don't have. Perhaps I'm missing something? I.e., I can dedicate some time around the merge window (not every one, but this may improve), but not much more. I don't think there are any "others" interested in what's going on on IXP4xx. Simply, there isn't anything of importance here. It won't cause severe conflicts (and "next" helps here), and I post my patches to the list just like all people do. Of course if you can see a better way (given the limitations), I'm open. BTW I still think I'm a part of the community, even if I don't submit code through arm-soc :-)
On Sat, Sep 29, 2012 at 11:38:31PM +0200, Krzysztof Halasa wrote: > Note I'm not only doing ARM, but also X86 and MIPS, with additional code > shared between them, and the "stable" part of it is what I'm paid for. > I can't simply work with arm-soc, none of my platforms will even boot > with pure arm-soc. I'm assuming that Linus' -rc kernels work for you, yes? So, that suggests there's something in arm-soc which is breaking your platforms, which means that you'll need to cook up a fix after or during the next merge window. You could instead cook that fix up _now_ before the merge window and have it ready, _or_ send the fix to arm-soc or even report the regression so that we don't end up with IXP4xx breaking at the next merge window.
Russell King - ARM Linux <linux@arm.linux.org.uk> writes: >> Note I'm not only doing ARM, but also X86 and MIPS, with additional code >> shared between them, and the "stable" part of it is what I'm paid for. >> I can't simply work with arm-soc, none of my platforms will even boot >> with pure arm-soc. > > I'm assuming that Linus' -rc kernels work for you, yes? No, but it's OK :-) I meant I need additional code for a) ARM and MIPS-based boards (off the shelf by Ubiquity, Gateworks etc., support ported mostly from OpenWRT), b) custom hardware used only by us. I hope to eventually submit a) upstream, then arm-soc and Linus' trees would work for me. I know it's a mess, but for now I have no options. BTW the situation with hardware supported only by OpenWRT is a part of the equation.
diff --git a/arch/arm/mach-ixp4xx/include/mach/qmgr.h b/arch/arm/mach-ixp4xx/include/mach/qmgr.h index 0a88d3b..4de8da5 100644 --- a/arch/arm/mach-ixp4xx/include/mach/qmgr.h +++ b/arch/arm/mach-ixp4xx/include/mach/qmgr.h @@ -86,7 +86,7 @@ void qmgr_release_queue(unsigned int queue); static inline void qmgr_put_entry(unsigned int queue, u32 val) { - const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT; + struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT; #if DEBUG_QMGR BUG_ON(!qmgr_queue_descs[queue]); /* not yet requested */ @@ -99,7 +99,7 @@ static inline void qmgr_put_entry(unsigned int queue, u32 val) static inline u32 qmgr_get_entry(unsigned int queue) { u32 val; - const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT; + const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT; val = __raw_readl(&qmgr_regs->acc[queue][0]); #if DEBUG_QMGR BUG_ON(!qmgr_queue_descs[queue]); /* not yet requested */ @@ -112,14 +112,14 @@ static inline u32 qmgr_get_entry(unsigned int queue) static inline int __qmgr_get_stat1(unsigned int queue) { - const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT; + const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT; return (__raw_readl(&qmgr_regs->stat1[queue >> 3]) >> ((queue & 7) << 2)) & 0xF; } static inline int __qmgr_get_stat2(unsigned int queue) { - const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT; + const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT; BUG_ON(queue >= HALF_QUEUES); return (__raw_readl(&qmgr_regs->stat2[queue >> 4]) >> ((queue & 0xF) << 1)) & 0x3; @@ -145,7 +145,7 @@ static inline int qmgr_stat_empty(unsigned int queue) */ static inline int qmgr_stat_below_low_watermark(unsigned int queue) { - const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT; + const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT; if (queue >= HALF_QUEUES) return (__raw_readl(&qmgr_regs->statne_h) >> (queue - HALF_QUEUES)) & 0x01; @@ -172,7 +172,7 @@ static inline int qmgr_stat_above_high_watermark(unsigned int queue) */ static inline int qmgr_stat_full(unsigned int queue) { - const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT; + const struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT; if (queue >= HALF_QUEUES) return (__raw_readl(&qmgr_regs->statf_h) >> (queue - HALF_QUEUES)) & 0x01; diff --git a/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c b/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c index 7c0584e..9d1b6b7 100644 --- a/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c +++ b/arch/arm/mach-ixp4xx/ixp4xx_qmgr.c @@ -14,7 +14,7 @@ #include <linux/module.h> #include <mach/qmgr.h> -static const struct qmgr_regs __iomem *qmgr_regs = (void __iomem *)IXP4XX_QMGR_BASE_VIRT; +static struct qmgr_regs __iomem *qmgr_regs = IXP4XX_QMGR_BASE_VIRT; static struct resource *mem_res; static spinlock_t qmgr_lock; static u32 used_sram_bitmap[4]; /* 128 16-dword pages */ @@ -32,7 +32,7 @@ void qmgr_set_irq(unsigned int queue, int src, spin_lock_irqsave(&qmgr_lock, flags); if (queue < HALF_QUEUES) { - const u32 __iomem *reg; + u32 __iomem *reg; int bit; BUG_ON(src > QUEUE_IRQ_SRC_NOT_FULL); reg = &qmgr_regs->irqsrc[queue >> 3]; /* 8 queues per u32 */
The ixp4xx queue manager uses "const struct qmgr_regs __iomem *" as the type for a pointer that is passed to __raw_writel, which is not allowed because of the const-ness. Dropping the 'const' keyword fixes the problem. While we're here, let's also drop the useless type cast. Without this patch, building ixp4xx_defconfig results in: In file included from arch/arm/mach-ixp4xx/ixp4xx_qmgr.c:15:0: arch/arm/mach-ixp4xx/include/mach/qmgr.h: In function 'qmgr_put_entry': arch/arm/mach-ixp4xx/include/mach/qmgr.h:96:2: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default] arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *' In file included from drivers/net/ethernet/xscale/ixp4xx_eth.c:41:0: arch/arm/mach-ixp4xx/include/mach/qmgr.h: In function 'qmgr_put_entry': arch/arm/mach-ixp4xx/include/mach/qmgr.h:96:2: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default] arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *' arch/arm/mach-ixp4xx/ixp4xx_qmgr.c: In function 'qmgr_set_irq': arch/arm/mach-ixp4xx/ixp4xx_qmgr.c:41:9: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default] arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *' Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Krzysztof Halasa <khc@pm.waw.pl> --- Krzysztof, please apply in your next branch so this problem goes away in 3.8. I realize it won't make 3.7 any more since the base patches are not in arm-soc, but it's bad if linux-next is broken. arch/arm/mach-ixp4xx/include/mach/qmgr.h | 12 ++++++------ arch/arm/mach-ixp4xx/ixp4xx_qmgr.c | 4 ++-- 2 files changed, 8 insertions(+), 8 deletions(-)