Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [GIT PULL v2] interconnect changes for 5.5
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Linux PM list <linux-pm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <dd4ff7e3-920d-979b-c29b-7535d84d360f@linaro.org>
 <20191108105355.GA683899@kroah.com>
From:   Georgi Djakov <georgi.djakov@linaro.org>
Openpgp: preference=signencrypt
Message-ID: <25808ada-dbe6-db38-c68d-26a263942a28@linaro.org>
Date:   Fri, 8 Nov 2019 13:47:51 +0200
MIME-Version: 1.0
In-Reply-To: <20191108105355.GA683899@kroah.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 8.11.19 г. 12:53 ч., Greg Kroah-Hartman wrote:
> On Fri, Nov 08, 2019 at 10:59:11AM +0200, Georgi Djakov wrote:
>> Hi Greg,
>>
>> This is the updated pull request with interconnect patches for the 5.5 merge
>> window. The details are in the signed tag. Please pull into char-misc-next.
> 
> Ugh, ok, can we just go back to sending patches instead?
> 
> The first two patches have "Fixes:" tags for older kernels, yet no
> stable tags.  That's not ok.

These two patches are for the current 5.4 release and you have them in your
char-misc-linus branch already. I assume that you will get them in -next later
via back merge anyway, so will drop them.
Should we use Fixes and stable tags always together and only when we fix
something in older kernels and not in the current one?

> For patch 5, you are playing "chicken" with what module gets loaded
> first, and in the end you're not going to win, only delay the
> inevitable.  We now have the driver core framework to support
> dependencies like this, please use that instead.

Yes, i keep an eye on this and am currently testing it.

> So, can you drop patch 5, fix up patches 1 and 2, and go back to sending
> patches instead of pull requests as if these were patches, I could have
> fixed up 1 and 2 myself.

Will do it!

Thanks,
Georgi