Re: Applied "ASoC: rsnd: don't call free_irq() on Parent SSI" to the asoc tree
Hi Mark
This patch was accepted on your topic branch now
1f8754d4daea5f257370a52a30fcb22798c54516
("ASoC: rsnd: don't call free_irq() on Parent SSI")
I'm sorry, but, this is needed to fix branch for v4.12-rcX too.
How to handle it ? can you cherry-pick it to mark/fix/rcar or can I
post it ?
> The patch
>
>ASoC: rsnd: don't call free_irq() on Parent SSI
>
> has been applied to the asoc tree at
>
>git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>
> From 1f8754d4daea5f257370a52a30fcb22798c54516 Mon Sep 17 00:00:00 2001
> From: Kuninori Morimoto
> Date: Tue, 16 May 2017 01:48:24 +
> Subject: [PATCH] ASoC: rsnd: don't call free_irq() on Parent SSI
>
> If SSI uses shared pin, some SSI will be used as parent SSI.
> Then, normal SSI's remove and Parent SSI's remove
> (these are same SSI) will be called when unbind or remove timing.
> In this case, free_irq() will be called twice.
> This patch solve this issue.
>
> Signed-off-by: Kuninori Morimoto
> Tested-by: Hiroyuki Yokoyama
> Reported-by: Hiroyuki Yokoyama
> Signed-off-by: Mark Brown
> ---
> sound/soc/sh/rcar/ssi.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
> index e43277a5068c..c224695c1484 100644
> --- a/sound/soc/sh/rcar/ssi.c
> +++ b/sound/soc/sh/rcar/ssi.c
> @@ -709,6 +709,11 @@ static int rsnd_ssi_dma_remove(struct rsnd_mod *mod,
> struct rsnd_priv *priv)
> {
> struct rsnd_ssi *ssi = rsnd_mod_to_ssi(mod);
> + struct rsnd_mod *ssi_parent_mod = rsnd_io_to_mod_ssip(io);
> +
> + /* Do nothing for SSI parent mod */
> + if (ssi_parent_mod == mod)
> + return 0;
>
> /* PIO will request IRQ again */
> free_irq(ssi->irq, mod);
> --
> 2.11.0
>
Re: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable
On Fri, Jun 9, 2017 at 9:50 AM, jmondi wrote: > On Fri, Jun 09, 2017 at 03:26:57PM +0800, Dong Aisheng wrote: >> > I see three options here: >> > >> > 1) Add "output-buffer-enable" and "input-buffer-enable" >> > we end up with >> > "output-high" >> > "output-low" >> > "input-enable" >> > "output-buffer-enable" >> > "input-buffer-enable" >> > >> > 2) Add "output-buffer-enable" only >> > we end up with >> > "output-high" >> > "output-low" >> > "input-enable" >> > "output-buffer-enable" >> > >> > Binding may be confusing as in one case we use "output-buffer-enable" >> > while in the other "input-enable" >> > >> > 3) Add "output-enable" only >> > "output-high" >> > "output-low" >> > "input-enable" >> > "output-enable" >> > >> > As you, I don't like "output-enable" that much but it pairs better with >> > "input-enable". >> > >> > I'll let you and DT people decide on this, as it's really an ABI definition >> > problem and you have better judgment there. >> > >> >> What's the final decision of this? > > I admit a was buying a bit of time and post-poned the gentle ping for > any final word on this. But since you're asking I'll second your > question :) I suspect it is time to quote Documentation/process/management-style.rst (Torvalds): 1) Decisions Everybody thinks managers make decisions, and that decision-making is important. The bigger and more painful the decision, the bigger the manager must be to make it. That's very deep and obvious, but it's not actually true. The name of the game is to **avoid** having to make a decision. In particular, if somebody tells you "choose (a) or (b), we really need you to decide on this", you're in trouble as a manager. The people you manage had better know the details better than you, so if they come to you for a technical decision, you're screwed. You're clearly not competent to make that decision for them. (It goes on, it's the best part of the entire Documentation/* dir in my opinion, please take the time to read it in full.) So: what do you guys, using this feature, and Andy, who raised serious concerns, think is the right binding? That is what *I* need to know. Yours, Linus Walleij
