Message ID | 87jzbp9hnt.fsf@bootlin.com |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL] mtd: topic branch for spi with Qcom changes | expand |
Hi Mark, On 24/12/2024 at 17:20:38 +01, Miquel Raynal <miquel.raynal@bootlin.com> wrote: > Hello Mark, > > I'm merging the Qcom series, in case you need a topic branch to apply > the spi bits (binding and driver), here it is. There is a breakage on x86 with this series, I'm applying another patch from Md Sadre Alam on top, so I'd suggest to not merge this branch and wait for the next cycle to take the spi bits if you're happy with them. Link: https://lore.kernel.org/linux-mtd/20250106131558.2219136-1-quic_mdalam@quicinc.com/T/#u Thanks, Miquèl
On Mon, Jan 06, 2025 at 02:49:18PM +0100, Miquel Raynal wrote: > On 24/12/2024 at 17:20:38 +01, Miquel Raynal <miquel.raynal@bootlin.com> wrote: > > I'm merging the Qcom series, in case you need a topic branch to apply > > the spi bits (binding and driver), here it is. > There is a breakage on x86 with this series, I'm applying another patch > from Md Sadre Alam on top, so I'd suggest to not merge this branch and > wait for the next cycle to take the spi bits if you're happy with them. Thanks for the heads up - I didn't pull it yet so as you suggest I can just leave it and pick things up from mainline.
Hi Mark, On 1/6/2025 9:06 PM, Mark Brown wrote: > On Mon, Jan 06, 2025 at 02:49:18PM +0100, Miquel Raynal wrote: >> On 24/12/2024 at 17:20:38 +01, Miquel Raynal <miquel.raynal@bootlin.com> wrote: > >>> I'm merging the Qcom series, in case you need a topic branch to apply >>> the spi bits (binding and driver), here it is. > >> There is a breakage on x86 with this series, I'm applying another patch >> from Md Sadre Alam on top, so I'd suggest to not merge this branch and >> wait for the next cycle to take the spi bits if you're happy with them. > > Thanks for the heads up - I didn't pull it yet so as you suggest I can > just leave it and pick things up from mainline. The QPIC raw nand patches are available in the linux-next. could you please pick the QPIC SPI NAND patches [1] [1] https://lore.kernel.org/all/20241120091507.1404368-7-quic_mdalam@quicinc.com/ Thanks, Alam.
On Mon, Feb 17, 2025 at 11:25:24AM +0530, Md Sadre Alam wrote: > On 1/6/2025 9:06 PM, Mark Brown wrote: > > Thanks for the heads up - I didn't pull it yet so as you suggest I can > > just leave it and pick things up from mainline. > The QPIC raw nand patches are available in the linux-next. could you please > pick the QPIC SPI NAND patches [1] > [1] > https://lore.kernel.org/all/20241120091507.1404368-7-quic_mdalam@quicinc.com/ That looks like it was posted back in November, I'd have expected anything for this release to have been posted after the merge window... Please don't send content free pings and please allow a reasonable time for review. People get busy, go on holiday, attend conferences and so on so unless there is some reason for urgency (like critical bug fixes) please allow at least a couple of weeks for review. If there have been review comments then people may be waiting for those to be addressed. Sending content free pings adds to the mail volume (if they are seen at all) which is often the problem and since they can't be reviewed directly if something has gone wrong you'll have to resend the patches anyway, so sending again is generally a better approach though there are some other maintainers who like them - if in doubt look at how patches for the subsystem are normally handled.
On 2/18/2025 8:24 PM, Mark Brown wrote: > On Mon, Feb 17, 2025 at 11:25:24AM +0530, Md Sadre Alam wrote: >> On 1/6/2025 9:06 PM, Mark Brown wrote: > >>> Thanks for the heads up - I didn't pull it yet so as you suggest I can >>> just leave it and pick things up from mainline. > >> The QPIC raw nand patches are available in the linux-next. could you please >> pick the QPIC SPI NAND patches [1] >> [1] >> https://lore.kernel.org/all/20241120091507.1404368-7-quic_mdalam@quicinc.com/ > > That looks like it was posted back in November, I'd have expected > anything for this release to have been posted after the merge window... > > Please don't send content free pings and please allow a reasonable time > for review. People get busy, go on holiday, attend conferences and so > on so unless there is some reason for urgency (like critical bug fixes) > please allow at least a couple of weeks for review. If there have been > review comments then people may be waiting for those to be addressed. > > Sending content free pings adds to the mail volume (if they are seen at > all) which is often the problem and since they can't be reviewed > directly if something has gone wrong you'll have to resend the patches > anyway, so sending again is generally a better approach though there are > some other maintainers who like them - if in doubt look at how patches > for the subsystem are normally handled. Sorry, will rebase, test and post a new version. Thanks, Alam.