All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Leon Romanovsky <leonro@nvidia.com>,
	Dave Ertman <david.m.ertman@intel.com>,
	alsa-devel@alsa-project.org, Takashi Iwai <tiwai@suse.de>,
	Mark Brown <broonie@kernel.org>,
	linux-rdma <linux-rdma@vger.kernel.org>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Doug Ledford <dledford@redhat.com>,
	Netdev <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Fred Oh <fred.oh@linux.intel.com>,
	Parav Pandit <parav@mellanox.com>,
	"Saleem, Shiraz" <shiraz.saleem@intel.com>,
	"Patil, Kiran" <kiran.patil@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 01/10] Add auxiliary bus support
Date: Wed, 18 Nov 2020 07:19:43 +0100	[thread overview]
Message-ID: <X7S8/1WOQbPTxfiF@kroah.com> (raw)
In-Reply-To: <CAPcyv4jXinvaLgtdpXTLLQ3sDOhvoBjF=7v7pba5rAd0g_rdow@mail.gmail.com>

On Tue, Nov 17, 2020 at 01:04:56PM -0800, Dan Williams wrote:
> On Mon, Nov 16, 2020 at 11:02 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Nov 17, 2020 at 07:30:00AM +0200, Leon Romanovsky wrote:
> > > On Fri, Nov 13, 2020 at 08:18:50AM -0800, Dave Ertman wrote:
> > > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> > > > It enables drivers to create an auxiliary_device and bind an
> > > > auxiliary_driver to it.
> > > >
> > > > The bus supports probe/remove shutdown and suspend/resume callbacks.
> > > > Each auxiliary_device has a unique string based id; driver binds to
> > > > an auxiliary_device based on this id through the bus.
> > > >
> > > > Co-developed-by: Kiran Patil <kiran.patil@intel.com>
> > > > Signed-off-by: Kiran Patil <kiran.patil@intel.com>
> > > > Co-developed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
> > > > Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
> > > > Co-developed-by: Fred Oh <fred.oh@linux.intel.com>
> > > > Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
> > > > Co-developed-by: Leon Romanovsky <leonro@nvidia.com>
> > > > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > > > Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> > > > Reviewed-by: Shiraz Saleem <shiraz.saleem@intel.com>
> > > > Reviewed-by: Parav Pandit <parav@mellanox.com>
> > > > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > > > Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
> > > > ---
> > >
> > > Greg,
> > >
> > > This horse was beaten to death, can we please progress with this patch?
> > > Create special topic branch or ack so I'll prepare this branch.
> > >
> > > We are in -rc4 now and we (Mellanox) can't hold our submissions anymore.
> > > My mlx5_core probe patches [1] were too intrusive and they are ready to
> > > be merged, Parav's patches got positive review as well [2] and will be
> > > taken next.
> > >
> > > We delayed and have in our internal queues the patches for VDPA, eswitch
> > > and followup for mlx5_core probe rework, but trapped due to this AUX bus
> > > patch.
> >
> > There are no deadlines for kernel patches here, sorry.  Give me some
> > time to properly review this, core kernel changes should not be rushed.
> >
> > Also, if you really want to blame someone for the delay, look at the
> > patch submitters not the reviewers, as they are the ones that took a
> > very long time with this over the lifecycle of this patchset, not me.  I
> > have provided many "instant" reviews of this patchset, and then months
> > went by between updates from them.
> 
> Please stop this finger pointing. It was already noted that the team,
> out of abundance of caution / deference to the process, decided not to
> push the patches while I was out on family leave. It's cruel to hold
> that against them, and if anyone is to blame it's me for not
> clarifying it was ok to proceed while I was out.

I'm not blaming anyone, I'm just getting pissed when people are
insisting that I do "quick reviews" for this patchset, which has been
happening by different people since the very beginning of this whole
feature, so I am trying to explain where others should be pointing their
frustration at instead of me if they really want to do such a thing
(hint, they shouldn't, but I wasn't explicit about that, sorry).

Combine this with the long delays between my reviews and a new patchset
submission, and on my end it's an extremely frustrating situation, which
frankly, makes me want to review this thing even less and less as I know
it's not going to be a fun or easy time when I do so.

Everyone needs to remember that there are no deadlines here, and the
people involved all have other things to work on at the same time, and
that there are a lot of different subsystems and moving parts all
involved.  So someone is going to get grumpy about it, and right now, it
seems to be me.  I know I need to review this, and complaining that I
haven't done so within 3 days of sending an updated patch set is not
helping anyone.

I'm going to try to carve out some time this week to review this
properly.  Hopefully there's no other major security "scares" popping up
like there was the past few weeks to divert me from this...

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: alsa-devel@alsa-project.org, Parav Pandit <parav@mellanox.com>,
	Takashi Iwai <tiwai@suse.de>, Netdev <netdev@vger.kernel.org>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Fred Oh <fred.oh@linux.intel.com>,
	linux-rdma <linux-rdma@vger.kernel.org>,
	Doug Ledford <dledford@redhat.com>,
	Mark Brown <broonie@kernel.org>,
	"Saleem, Shiraz" <shiraz.saleem@intel.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Dave Ertman <david.m.ertman@intel.com>,
	Leon Romanovsky <leonro@nvidia.com>,
	David Miller <davem@davemloft.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Patil, Kiran" <kiran.patil@intel.com>
Subject: Re: [PATCH v4 01/10] Add auxiliary bus support
Date: Wed, 18 Nov 2020 07:19:43 +0100	[thread overview]
Message-ID: <X7S8/1WOQbPTxfiF@kroah.com> (raw)
In-Reply-To: <CAPcyv4jXinvaLgtdpXTLLQ3sDOhvoBjF=7v7pba5rAd0g_rdow@mail.gmail.com>

On Tue, Nov 17, 2020 at 01:04:56PM -0800, Dan Williams wrote:
> On Mon, Nov 16, 2020 at 11:02 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Nov 17, 2020 at 07:30:00AM +0200, Leon Romanovsky wrote:
> > > On Fri, Nov 13, 2020 at 08:18:50AM -0800, Dave Ertman wrote:
> > > > Add support for the Auxiliary Bus, auxiliary_device and auxiliary_driver.
> > > > It enables drivers to create an auxiliary_device and bind an
> > > > auxiliary_driver to it.
> > > >
> > > > The bus supports probe/remove shutdown and suspend/resume callbacks.
> > > > Each auxiliary_device has a unique string based id; driver binds to
> > > > an auxiliary_device based on this id through the bus.
> > > >
> > > > Co-developed-by: Kiran Patil <kiran.patil@intel.com>
> > > > Signed-off-by: Kiran Patil <kiran.patil@intel.com>
> > > > Co-developed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
> > > > Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
> > > > Co-developed-by: Fred Oh <fred.oh@linux.intel.com>
> > > > Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
> > > > Co-developed-by: Leon Romanovsky <leonro@nvidia.com>
> > > > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > > > Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> > > > Reviewed-by: Shiraz Saleem <shiraz.saleem@intel.com>
> > > > Reviewed-by: Parav Pandit <parav@mellanox.com>
> > > > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > > > Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
> > > > ---
> > >
> > > Greg,
> > >
> > > This horse was beaten to death, can we please progress with this patch?
> > > Create special topic branch or ack so I'll prepare this branch.
> > >
> > > We are in -rc4 now and we (Mellanox) can't hold our submissions anymore.
> > > My mlx5_core probe patches [1] were too intrusive and they are ready to
> > > be merged, Parav's patches got positive review as well [2] and will be
> > > taken next.
> > >
> > > We delayed and have in our internal queues the patches for VDPA, eswitch
> > > and followup for mlx5_core probe rework, but trapped due to this AUX bus
> > > patch.
> >
> > There are no deadlines for kernel patches here, sorry.  Give me some
> > time to properly review this, core kernel changes should not be rushed.
> >
> > Also, if you really want to blame someone for the delay, look at the
> > patch submitters not the reviewers, as they are the ones that took a
> > very long time with this over the lifecycle of this patchset, not me.  I
> > have provided many "instant" reviews of this patchset, and then months
> > went by between updates from them.
> 
> Please stop this finger pointing. It was already noted that the team,
> out of abundance of caution / deference to the process, decided not to
> push the patches while I was out on family leave. It's cruel to hold
> that against them, and if anyone is to blame it's me for not
> clarifying it was ok to proceed while I was out.

I'm not blaming anyone, I'm just getting pissed when people are
insisting that I do "quick reviews" for this patchset, which has been
happening by different people since the very beginning of this whole
feature, so I am trying to explain where others should be pointing their
frustration at instead of me if they really want to do such a thing
(hint, they shouldn't, but I wasn't explicit about that, sorry).

Combine this with the long delays between my reviews and a new patchset
submission, and on my end it's an extremely frustrating situation, which
frankly, makes me want to review this thing even less and less as I know
it's not going to be a fun or easy time when I do so.

Everyone needs to remember that there are no deadlines here, and the
people involved all have other things to work on at the same time, and
that there are a lot of different subsystems and moving parts all
involved.  So someone is going to get grumpy about it, and right now, it
seems to be me.  I know I need to review this, and complaining that I
haven't done so within 3 days of sending an updated patch set is not
helping anyone.

I'm going to try to carve out some time this week to review this
properly.  Hopefully there's no other major security "scares" popping up
like there was the past few weeks to divert me from this...

thanks,

greg k-h

  reply	other threads:[~2020-11-18  6:19 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13 16:18 [PATCH v4 00/10] Auxiliary bus implementation and SOF multi-client support Dave Ertman
2020-11-13 16:18 ` Dave Ertman
2020-11-13 16:18 ` [PATCH v4 01/10] Add auxiliary bus support Dave Ertman
2020-11-13 16:18   ` Dave Ertman
2020-11-17  5:30   ` Leon Romanovsky
2020-11-17  5:30     ` Leon Romanovsky
2020-11-17  7:02     ` Greg KH
2020-11-17  7:02       ` Greg KH
2020-11-17  7:16       ` Leon Romanovsky
2020-11-17  7:16         ` Leon Romanovsky
2020-11-17 21:04       ` Dan Williams
2020-11-17 21:04         ` Dan Williams
2020-11-18  6:19         ` Greg KH [this message]
2020-11-18  6:19           ` Greg KH
2020-11-17 13:48     ` Mark Brown
2020-11-17 13:48       ` Mark Brown
2020-11-17 13:57       ` Leon Romanovsky
2020-11-17 13:57         ` Leon Romanovsky
2020-11-17 15:48         ` Greg KH
2020-11-17 15:48           ` Greg KH
2020-11-17 19:39   ` Martin Habets
2020-11-17 19:39     ` Martin Habets
2020-11-13 16:18 ` [PATCH v4 02/10] ASoC: SOF: Introduce descriptors for SOF client Dave Ertman
2020-11-13 16:18   ` Dave Ertman
2020-11-13 16:18 ` [PATCH v4 03/10] ASoC: SOF: Create client driver for IPC test Dave Ertman
2020-11-13 16:18   ` Dave Ertman
2020-11-13 16:18 ` [PATCH v4 04/10] ASoC: SOF: ops: Add ops for client registration Dave Ertman
2020-11-13 16:18   ` Dave Ertman
2020-11-13 16:18 ` [PATCH v4 05/10] ASoC: SOF: Intel: Define " Dave Ertman
2020-11-13 16:18   ` Dave Ertman
2020-11-13 17:56   ` kernel test robot
2020-11-13 16:18 ` [PATCH v4 06/10] ASoC: SOF: Intel: Remove IPC flood test support in SOF core Dave Ertman
2020-11-13 16:18   ` Dave Ertman
2020-11-13 16:18 ` [PATCH v4 07/10] ASoC: SOF: sof-client: Add client APIs to access probes ops Dave Ertman
2020-11-13 16:18   ` Dave Ertman
2020-11-13 16:18 ` [PATCH v4 08/10] ASoC: SOF: compress: move and export sof_probe_compr_ops Dave Ertman
2020-11-13 16:18   ` Dave Ertman
2020-11-13 16:18 ` [PATCH v4 09/10] ASoC: SOF: Add new client driver for probes support Dave Ertman
2020-11-13 16:18   ` Dave Ertman
2020-11-13 16:18 ` [PATCH v4 10/10] ASoC: SOF: Intel: CNL: register probes client Dave Ertman
2020-11-13 16:18   ` Dave Ertman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=X7S8/1WOQbPTxfiF@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=davem@davemloft.net \
    --cc=david.m.ertman@intel.com \
    --cc=dledford@redhat.com \
    --cc=fred.oh@linux.intel.com \
    --cc=jgg@nvidia.com \
    --cc=kiran.patil@intel.com \
    --cc=kuba@kernel.org \
    --cc=leonro@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=parav@mellanox.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=shiraz.saleem@intel.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.