On Wed, Apr 05, 2017 at 04:04:49PM +0530, Amit Pundir wrote:
On 5 April 2017 at 15:48, Amit Pundir amit.pundir@linaro.org wrote:
On 5 April 2017 at 14:18, Greg KH gregkh@google.com wrote:
On Wed, Apr 05, 2017 at 01:55:59PM +0530, Amit Pundir wrote:
On 4 April 2017 at 11:46, Greg KH gregkh@google.com wrote:
On Mon, Apr 03, 2017 at 11:57:22PM +0530, Amit Pundir wrote:
On 3 April 2017 at 23:31, Greg KH gregkh@google.com wrote: > On Mon, Apr 03, 2017 at 11:06:23PM +0530, Amit Pundir wrote: >> Hi Greg, >> >> For your consideration following upstream patches taken from lede >> source tree[1] targeted for 4.9.y. > > <snip> > > Can you send this to the stable@ list instead so that everyone can see > it there?
Sure. Should I send them in the same format as this one i.e. only git commit ID list?
Either is fine, a list of git commit ids is simple to handle for me.
> Also, are any of these to be applied to 4.10? And, what order do these > apply in, the list you gave, or backwards?
I did not apply them on 4.10 as such but I'm sure few of them are applicable to 4.10. Should I send you a patch list for 4.10 as well?
Yes please.
For 4.10, I'll send the list of patches based on the lede stable changes which make it to stable-queue for 4.9. Because few patches for-4.9 are NACKed by Rafał Miłecki already. Quoting him here, "Some of these patches are clean ups, not a really important fixes." Though he didn't mention which patches he meant. I checked back the list of patches again and assume he meant following patches of his and others:
5d1f2d2 (ARM: dts: BCM5301X: Set 5 GHz wireless frequency limits) 155e8b3 (clk: bcm: Support rate change propagation on bcm2835 clocks) d86d46a (clk: bcm: Allow rate change propagation to PLLH_AUX on VEC clock) 2aab7a2 (clk: bcm: Fix 'maybe-uninitialized' warning in bcm2835_clock_choose_div_and_prate()) 5548609 (clk: bcm2835: Don't rate change PLLs on behalf of DSI PLL dividers.) 8a39e9f (clk: bcm2835: Register the DSI0/DSI1 pixel clocks.) 3f91958 (clk: bcm2835: Add leaf clock measurement support, disabled by default) 40be0dd (net: add devm version of alloc_etherdev_mqs function) 34a5102 (net: bgmac: allocate struct bgmac just once & don't copy it) aa8863e (net: bgmac: drop struct bcma_mdio we don't need anymore) 36401cb (brcmfmac: be more verbose when PSM's watchdog fires) 9587a01 (brcmfmac: merge two brcmf_err macros into one) 087fa71 (brcmfmac: switch to C function (__brcmf_err) for printing errors) d063055 (brcmfmac: merge two remaining brcmf_err macros) 91b6328 (brcmfmac: Use net_device_stats from struct net_device)
Why not ask on the list to be sure?
So I dropped above set of patches and below is the new list of patches from lede for stable-4.9 consideration. To be cherry-picked from top to bottom:
09f3510 (ARM: BCM5301X: Add back handler ignoring external)
0c2bf9f (ARM: dts: BCM5301X: Correct GIC_PPI interrupt flags)
6e347b5 (PCI: iproc: Save host bridge window resource in struct)
6c356ed (MIPS: Lantiq: Fix cascaded IRQ setup)
e247454 (i2c: bcm2835: Fix hang for writing messages larger than 16 bytes)
d4030d7 (i2c: bcm2835: Protect against unexpected TXW/RXR interrupts)
23c9540 (i2c: bcm2835: Use dev_dbg logging on transfer errors) The only reason I'm keeping this ^^ cleanup patch in the list is because it helps following patch (8d2cc5cc) apply cleanly.
8d2cc5cc (i2c: bcm2835: Can't support I2C_M_IGNORE_NAK)
2201ac6 (dmaengine: bcm2835: Fix cyclic DMA period splitting)
cd4b1e3 (usb: dwc2: Remove unnecessary kfree)
bd5d213 (mtd: bcm47xxpart: fix parsing first block after aligned TRX)
3ec7544 (of: Add check to of_scan_flat_dt() before accessing initial_boot_params)
7272416 (rt2500usb: don't mark register accesses as inline)
f4737a6 (brcmfmac: check brcmf_bus_get_memdump result for error)
93c7018 (rt2x00usb: do not anchor rx and tx urb's)
0488a61 (rt2x00usb: fix anchor initialization)
a083c8f (rt2x00: Fix incorrect usage of CONFIG_RT2X00_LIB_USB)
6232c17 (rt2x00: avoid introducing a USB dependency in the rt2x00lib module)
Build tested on arm/arm64 + allmodconfig.
Again, please post on stable@ so that others can take advantage of this, and review them.
I was preparing v2 of my proposed lede stable-4.9 commits to stable and then I see your email just now on stable@vger. Have you started pulling the patches already? Should I not send v2 now? Please confirm.
Sent v2 anyway. Thanks.
Not a problem, thanks for sending them, I'll review them in the next few days...
greg k-h