Hello,
the reference handling in siox is a bit strange. With
siox_master_alloc() to get a reference on the master that is passed to
the core calling siox_master_register(). So until siox_master_register()
is called successfully the driver has to call siox_master_put() in the
error path, but on remove siox_master_unregister cares for that. While
that technically works, it's unusual and surprising to use. This serie's
first patch cleans that up and then introduces devm functions to make it
even easier to use.
A nice (and intended) side effect is that the gpio bus driver gets rid
of it's remove callback, so I don't have to adapt it for my quest that
changes the prototype of .remove().
Best regards
Uwe
Uwe Kleine-König (4):
siox: Don't pass the reference on a master in siox_master_register()
siox: Provide a devm variant of siox_master_alloc()
siox: Provide a devm variant of siox_master_register()
siox: bus-gpio: Simplify using devm_siox_* functions
drivers/siox/siox-bus-gpio.c | 62 ++++++++++++------------------------
drivers/siox/siox-core.c | 45 ++++++++++++++++++++++++++
drivers/siox/siox.h | 4 +++
3 files changed, 69 insertions(+), 42 deletions(-)
base-commit: d37e1e4c52bc60578969f391fb81f947c3e83118
--
2.43.0
This allows to simplify siox master drivers in the next step.
Signed-off-by: Uwe Kleine-König <[email protected]>
---
drivers/siox/siox-core.c | 19 +++++++++++++++++++
drivers/siox/siox.h | 2 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
index 9dd0bda03db3..8d7cb9e24efb 100644
--- a/drivers/siox/siox-core.c
+++ b/drivers/siox/siox-core.c
@@ -794,6 +794,25 @@ void siox_master_unregister(struct siox_master *smaster)
}
EXPORT_SYMBOL_GPL(siox_master_unregister);
+static void devm_siox_master_unregister(void *data)
+{
+ struct siox_master *smaster = data;
+
+ siox_master_unregister(smaster);
+}
+
+int devm_siox_master_register(struct device *dev, struct siox_master *smaster)
+{
+ int ret;
+
+ ret = siox_master_register(smaster);
+ if (ret)
+ return ret;
+
+ return devm_add_action_or_reset(dev, devm_siox_master_unregister, smaster);
+}
+EXPORT_SYMBOL_GPL(devm_siox_master_register);
+
static struct siox_device *siox_device_add(struct siox_master *smaster,
const char *type, size_t inbytes,
size_t outbytes, u8 statustype)
diff --git a/drivers/siox/siox.h b/drivers/siox/siox.h
index b227e18b697a..513f2c8312f7 100644
--- a/drivers/siox/siox.h
+++ b/drivers/siox/siox.h
@@ -49,3 +49,5 @@ struct siox_master *devm_siox_master_alloc(struct device *dev, size_t size);
int siox_master_register(struct siox_master *smaster);
void siox_master_unregister(struct siox_master *smaster);
+
+int devm_siox_master_register(struct device *dev, struct siox_master *smaster);
--
2.43.0
While it's technically fine to pass the ownership of the reference on
a struct siox_master from the caller of siox_master_register() to the
framework this is hard to use. Instead let the framework take its own
reference (that is freed in siox_master_unregister()) and drop the bus
driver's reference in its remove callback.
Signed-off-by: Uwe Kleine-König <[email protected]>
---
drivers/siox/siox-bus-gpio.c | 2 ++
drivers/siox/siox-core.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/siox/siox-bus-gpio.c b/drivers/siox/siox-bus-gpio.c
index aeefeb725524..fdf20fe80059 100644
--- a/drivers/siox/siox-bus-gpio.c
+++ b/drivers/siox/siox-bus-gpio.c
@@ -149,6 +149,8 @@ static int siox_gpio_remove(struct platform_device *pdev)
siox_master_unregister(master);
+ siox_master_put(master);
+
return 0;
}
diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
index 561408583b2b..d4acab7036d6 100644
--- a/drivers/siox/siox-core.c
+++ b/drivers/siox/siox-core.c
@@ -717,6 +717,8 @@ int siox_master_register(struct siox_master *smaster)
if (!smaster->pushpull)
return -EINVAL;
+ get_device(&smaster->dev);
+
dev_set_name(&smaster->dev, "siox-%d", smaster->busno);
mutex_init(&smaster->lock);
--
2.43.0
This allows to simplify siox master drivers in the next step.
Signed-off-by: Uwe Kleine-König <[email protected]>
---
drivers/siox/siox-core.c | 24 ++++++++++++++++++++++++
drivers/siox/siox.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
index d4acab7036d6..9dd0bda03db3 100644
--- a/drivers/siox/siox-core.c
+++ b/drivers/siox/siox-core.c
@@ -707,6 +707,30 @@ struct siox_master *siox_master_alloc(struct device *dev,
}
EXPORT_SYMBOL_GPL(siox_master_alloc);
+static void devm_siox_master_put(void *data)
+{
+ struct siox_master *smaster = data;
+
+ siox_master_put(smaster);
+}
+
+struct siox_master *devm_siox_master_alloc(struct device *dev,
+ size_t size)
+{
+ struct siox_master *smaster;
+ int ret;
+
+ smaster = siox_master_alloc(dev, size);
+ if (!smaster)
+ return NULL;
+
+ ret = devm_add_action_or_reset(dev, devm_siox_master_put, smaster);
+ if (ret)
+ return NULL;
+
+ return smaster;
+}
+
int siox_master_register(struct siox_master *smaster)
{
int ret;
diff --git a/drivers/siox/siox.h b/drivers/siox/siox.h
index f08b43b713c5..b227e18b697a 100644
--- a/drivers/siox/siox.h
+++ b/drivers/siox/siox.h
@@ -45,5 +45,7 @@ static inline void siox_master_put(struct siox_master *smaster)
put_device(&smaster->dev);
}
+struct siox_master *devm_siox_master_alloc(struct device *dev, size_t size);
+
int siox_master_register(struct siox_master *smaster);
void siox_master_unregister(struct siox_master *smaster);
--
2.43.0
With the devm variant of siox_master_allocate() and
siox_master_register() the remove callback can be dropped. This also
simplifies the error paths in the probe function.
Signed-off-by: Uwe Kleine-König <[email protected]>
---
drivers/siox/siox-bus-gpio.c | 64 +++++++++++-------------------------
1 file changed, 20 insertions(+), 44 deletions(-)
diff --git a/drivers/siox/siox-bus-gpio.c b/drivers/siox/siox-bus-gpio.c
index fdf20fe80059..9e01642e72de 100644
--- a/drivers/siox/siox-bus-gpio.c
+++ b/drivers/siox/siox-bus-gpio.c
@@ -91,65 +91,42 @@ static int siox_gpio_probe(struct platform_device *pdev)
int ret;
struct siox_master *smaster;
- smaster = siox_master_alloc(&pdev->dev, sizeof(*ddata));
- if (!smaster) {
- dev_err(dev, "failed to allocate siox master\n");
- return -ENOMEM;
- }
+ smaster = devm_siox_master_alloc(dev, sizeof(*ddata));
+ if (!smaster)
+ return dev_err_probe(dev, -ENOMEM,
+ "failed to allocate siox master\n");
platform_set_drvdata(pdev, smaster);
ddata = siox_master_get_devdata(smaster);
ddata->din = devm_gpiod_get(dev, "din", GPIOD_IN);
- if (IS_ERR(ddata->din)) {
- ret = dev_err_probe(dev, PTR_ERR(ddata->din),
- "Failed to get din GPIO\n");
- goto err;
- }
+ if (IS_ERR(ddata->din))
+ return dev_err_probe(dev, PTR_ERR(ddata->din),
+ "Failed to get din GPIO\n");
ddata->dout = devm_gpiod_get(dev, "dout", GPIOD_OUT_LOW);
- if (IS_ERR(ddata->dout)) {
- ret = dev_err_probe(dev, PTR_ERR(ddata->dout),
- "Failed to get dout GPIO\n");
- goto err;
- }
+ if (IS_ERR(ddata->dout))
+ return dev_err_probe(dev, PTR_ERR(ddata->dout),
+ "Failed to get dout GPIO\n");
ddata->dclk = devm_gpiod_get(dev, "dclk", GPIOD_OUT_LOW);
- if (IS_ERR(ddata->dclk)) {
- ret = dev_err_probe(dev, PTR_ERR(ddata->dclk),
- "Failed to get dclk GPIO\n");
- goto err;
- }
+ if (IS_ERR(ddata->dclk))
+ return dev_err_probe(dev, PTR_ERR(ddata->dclk),
+ "Failed to get dclk GPIO\n");
ddata->dld = devm_gpiod_get(dev, "dld", GPIOD_OUT_LOW);
- if (IS_ERR(ddata->dld)) {
- ret = dev_err_probe(dev, PTR_ERR(ddata->dld),
- "Failed to get dld GPIO\n");
- goto err;
- }
+ if (IS_ERR(ddata->dld))
+ return dev_err_probe(dev, PTR_ERR(ddata->dld),
+ "Failed to get dld GPIO\n");
smaster->pushpull = siox_gpio_pushpull;
/* XXX: determine automatically like spi does */
smaster->busno = 0;
- ret = siox_master_register(smaster);
- if (ret) {
- dev_err_probe(dev, ret,
- "Failed to register siox master\n");
-err:
- siox_master_put(smaster);
- }
-
- return ret;
-}
-
-static int siox_gpio_remove(struct platform_device *pdev)
-{
- struct siox_master *master = platform_get_drvdata(pdev);
-
- siox_master_unregister(master);
-
- siox_master_put(master);
+ ret = devm_siox_master_register(dev, smaster);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to register siox master\n");
return 0;
}
@@ -162,7 +139,6 @@ MODULE_DEVICE_TABLE(of, siox_gpio_dt_ids);
static struct platform_driver siox_gpio_driver = {
.probe = siox_gpio_probe,
- .remove = siox_gpio_remove,
.driver = {
.name = DRIVER_NAME,
--
2.43.0
Hello Uwe, Hello Greg,
On Mon, Feb 19, 2024 at 08:46:28AM +0100, Uwe Kleine-K?nig wrote:
> Hello,
>
> the reference handling in siox is a bit strange. With
> siox_master_alloc() to get a reference on the master that is passed to
> the core calling siox_master_register(). So until siox_master_register()
> is called successfully the driver has to call siox_master_put() in the
> error path, but on remove siox_master_unregister cares for that. While
> that technically works, it's unusual and surprising to use. This serie's
> first patch cleans that up and then introduces devm functions to make it
> even easier to use.
>
> A nice (and intended) side effect is that the gpio bus driver gets rid
> of it's remove callback, so I don't have to adapt it for my quest that
> changes the prototype of .remove().
I only compile tested this as I currently do not have access to test
hardware.
The series looks sensible.
Acked-by: Thorsten Scherer <[email protected]>
@gregkh: Would you please pick up Uwe's series as well?
Thank you both.
Best regards
Thorsten
> Best regards
> Uwe
>
> Uwe Kleine-K?nig (4):
> siox: Don't pass the reference on a master in siox_master_register()
> siox: Provide a devm variant of siox_master_alloc()
> siox: Provide a devm variant of siox_master_register()
> siox: bus-gpio: Simplify using devm_siox_* functions
>
> drivers/siox/siox-bus-gpio.c | 62 ++++++++++++------------------------
> drivers/siox/siox-core.c | 45 ++++++++++++++++++++++++++
> drivers/siox/siox.h | 4 +++
> 3 files changed, 69 insertions(+), 42 deletions(-)
>
>
> base-commit: d37e1e4c52bc60578969f391fb81f947c3e83118
> --
> 2.43.0
>
Hello,
On Tue, Feb 27, 2024 at 11:21:24AM +0100, Thorsten Scherer wrote:
> On Mon, Feb 19, 2024 at 08:46:28AM +0100, Uwe Kleine-K?nig wrote:
> The series looks sensible.
>
> Acked-by: Thorsten Scherer <[email protected]>
>
> @gregkh: Would you please pick up Uwe's series as well?
There are currently six patches for drivers/siox waiting to be applied.
(Two by Ricardo and four by me.) Thorsten asked Greg to do so. Greg
didn't pick these up yet though. So I collected them and put them to a
branch at:
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git siox/for-next
I'd like to get them in during the next development cycle.
Greg, what is easiest for you? Are they still on your list of open
patches and we (I) need just a bit more patience? Or should I send a PR
to Linus when the merge window opens?
Stephen: It would be nice to get this above branch into next, no matter
if the patches make it in via Greg or me. Could you please add this
branch to your list for next? If Greg will apply them, I'll empty this
branch to not get duplicates.
Thanks to all involved people,
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Hi Uwe,
On Wed, 6 Mar 2024 19:24:38 +0100 Uwe Kleine-König <[email protected]> wrote:
>
> On Tue, Feb 27, 2024 at 11:21:24AM +0100, Thorsten Scherer wrote:
> > On Mon, Feb 19, 2024 at 08:46:28AM +0100, Uwe Kleine-König wrote:
> > The series looks sensible.
> >
> > Acked-by: Thorsten Scherer <[email protected]>
> >
> > @gregkh: Would you please pick up Uwe's series as well?
>
> There are currently six patches for drivers/siox waiting to be applied.
> (Two by Ricardo and four by me.) Thorsten asked Greg to do so. Greg
> didn't pick these up yet though. So I collected them and put them to a
> branch at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git siox/for-next
>
> I'd like to get them in during the next development cycle.
>
> Greg, what is easiest for you? Are they still on your list of open
> patches and we (I) need just a bit more patience? Or should I send a PR
> to Linus when the merge window opens?
>
> Stephen: It would be nice to get this above branch into next, no matter
> if the patches make it in via Greg or me. Could you please add this
> branch to your list for next? If Greg will apply them, I'll empty this
> branch to not get duplicates.
Added from today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgement of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
[email protected]
--
Cheers,
Stephen Rothwell
On Wed, Mar 06, 2024 at 07:24:38PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Tue, Feb 27, 2024 at 11:21:24AM +0100, Thorsten Scherer wrote:
> > On Mon, Feb 19, 2024 at 08:46:28AM +0100, Uwe Kleine-K?nig wrote:
> > The series looks sensible.
> >
> > Acked-by: Thorsten Scherer <[email protected]>
> >
> > @gregkh: Would you please pick up Uwe's series as well?
>
> There are currently six patches for drivers/siox waiting to be applied.
> (Two by Ricardo and four by me.) Thorsten asked Greg to do so. Greg
> didn't pick these up yet though. So I collected them and put them to a
> branch at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git siox/for-next
>
> I'd like to get them in during the next development cycle.
>
> Greg, what is easiest for you? Are they still on your list of open
> patches and we (I) need just a bit more patience? Or should I send a PR
> to Linus when the merge window opens?
Yes, they are on my list, but I am way behind, sorry. But hey, a pull
request is faster, I'll go take this now, thanks!
Oops, nope, I get the following build error with this tree:
ERROR: modpost: "devm_siox_master_alloc" [drivers/siox/siox-bus-gpio.ko] undefined!
So are you sure you tested this?
thanks,
greg k-h
Hey Greg,
On Wed, Mar 06, 2024 at 10:46:43PM +0000, Greg Kroah-Hartman wrote:
> On Wed, Mar 06, 2024 at 07:24:38PM +0100, Uwe Kleine-K?nig wrote:
> > On Tue, Feb 27, 2024 at 11:21:24AM +0100, Thorsten Scherer wrote:
> > > On Mon, Feb 19, 2024 at 08:46:28AM +0100, Uwe Kleine-K?nig wrote:
> > > The series looks sensible.
> > >
> > > Acked-by: Thorsten Scherer <[email protected]>
> > >
> > > @gregkh: Would you please pick up Uwe's series as well?
> >
> > There are currently six patches for drivers/siox waiting to be applied.
> > (Two by Ricardo and four by me.) Thorsten asked Greg to do so. Greg
> > didn't pick these up yet though. So I collected them and put them to a
> > branch at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git siox/for-next
> >
> > I'd like to get them in during the next development cycle.
> >
> > Greg, what is easiest for you? Are they still on your list of open
> > patches and we (I) need just a bit more patience? Or should I send a PR
> > to Linus when the merge window opens?
>
> Yes, they are on my list, but I am way behind, sorry. But hey, a pull
> request is faster, I'll go take this now, thanks!
>
> Oops, nope, I get the following build error with this tree:
> ERROR: modpost: "devm_siox_master_alloc" [drivers/siox/siox-bus-gpio.ko] undefined!
>
> So are you sure you tested this?
Dang, Stephen notices that, too. TIL if I only do:
make allmodconfig drivers/siox/
a missing EXPORT_SYMBOL doesn't make the build fail.
I squashed
diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
index ae103349c91a..24a45920a240 100644
--- a/drivers/siox/siox-core.c
+++ b/drivers/siox/siox-core.c
@@ -730,6 +730,7 @@ struct siox_master *devm_siox_master_alloc(struct device *dev,
return smaster;
}
+EXPORT_SYMBOL_GPL(devm_siox_master_alloc);
int siox_master_register(struct siox_master *smaster)
{
into the offending commit in my above branch and did some more extensive
build testing.
Sorry
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Hello,
On Mon, Feb 19, 2024 at 08:46:30AM +0100, Uwe Kleine-K?nig wrote:
> +struct siox_master *devm_siox_master_alloc(struct device *dev,
> + size_t size)
> +{
> + struct siox_master *smaster;
> + int ret;
> +
> + smaster = siox_master_alloc(dev, size);
> + if (!smaster)
> + return NULL;
> +
> + ret = devm_add_action_or_reset(dev, devm_siox_master_put, smaster);
> + if (ret)
> + return NULL;
> +
> + return smaster;
> +}
Here is missing an EXPORT_SYMBOL_GPL for devm_siox_master_alloc(). I
squashed this into to commit I created. Find the fixed commit at
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git siox/for-next
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On Thu, Mar 07, 2024 at 08:13:55AM +0100, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Mon, Feb 19, 2024 at 08:46:30AM +0100, Uwe Kleine-K?nig wrote:
> > +struct siox_master *devm_siox_master_alloc(struct device *dev,
> > + size_t size)
> > +{
> > + struct siox_master *smaster;
> > + int ret;
> > +
> > + smaster = siox_master_alloc(dev, size);
> > + if (!smaster)
> > + return NULL;
> > +
> > + ret = devm_add_action_or_reset(dev, devm_siox_master_put, smaster);
> > + if (ret)
> > + return NULL;
> > +
> > + return smaster;
> > +}
>
> Here is missing an EXPORT_SYMBOL_GPL for devm_siox_master_alloc(). I
> squashed this into to commit I created. Find the fixed commit at
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git siox/for-next
Can you send me a "real" git pull request so that I can verify it is
what you say it is (ideally with a signed tag)?
thanks,
greg k-h
Hello Greg,
On Thu, Mar 07, 2024 at 07:29:59AM +0000, Greg Kroah-Hartman wrote:
> On Thu, Mar 07, 2024 at 08:13:55AM +0100, Uwe Kleine-K?nig wrote:
> > On Mon, Feb 19, 2024 at 08:46:30AM +0100, Uwe Kleine-K?nig wrote:
> > > +struct siox_master *devm_siox_master_alloc(struct device *dev,
> > > + size_t size)
> > > +{
> > > + struct siox_master *smaster;
> > > + int ret;
> > > +
> > > + smaster = siox_master_alloc(dev, size);
> > > + if (!smaster)
> > > + return NULL;
> > > +
> > > + ret = devm_add_action_or_reset(dev, devm_siox_master_put, smaster);
> > > + if (ret)
> > > + return NULL;
> > > +
> > > + return smaster;
> > > +}
> >
> > Here is missing an EXPORT_SYMBOL_GPL for devm_siox_master_alloc(). I
> > squashed this into to commit I created. Find the fixed commit at
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git siox/for-next
>
> Can you send me a "real" git pull request so that I can verify it is
> what you say it is (ideally with a signed tag)?
Sure, can do. I will do that tomorrow when (and if) my branch is in next
and so got a bit more exposure.
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Hello Greg,
On Thu, Mar 07, 2024 at 09:38:07AM +0100, Uwe Kleine-K?nig wrote:
> On Thu, Mar 07, 2024 at 07:29:59AM +0000, Greg Kroah-Hartman wrote:
> > Can you send me a "real" git pull request so that I can verify it is
> > what you say it is (ideally with a signed tag)?
>
> Sure, can do. I will do that tomorrow when (and if) my branch is in next
> and so got a bit more exposure.
That has worked so far. So here comes the requested pull request. I
dropped the two patches you collected in the meantime in your
char-misc-next branch. The two branches (i.e. your char-misc-next and
this PR's tag) merge without conflict.
The following changes since commit 6613476e225e090cc9aad49be7fa504e290dd33d:
Linux 6.8-rc1 (2024-01-21 14:11:32 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git tags/siox/for-greg-6.9-rc1
for you to fetch changes up to db418d5f1ca5b7bafc8eaa9393ea18a7901bb0ed:
siox: bus-gpio: Simplify using devm_siox_* functions (2024-03-08 22:01:10 +0100)
Please pull this for the 6.9-rc1 merge window.
Thanks
Uwe
----------------------------------------------------------------
SIOX changes for 6.9-rc1
These patches rework how siox device registration works. This allows to
simplify the gpio bus driver using two new devm functions.
----------------------------------------------------------------
Uwe Kleine-K?nig (4):
siox: Don't pass the reference on a master in siox_master_register()
siox: Provide a devm variant of siox_master_alloc()
siox: Provide a devm variant of siox_master_register()
siox: bus-gpio: Simplify using devm_siox_* functions
drivers/siox/siox-bus-gpio.c | 62 ++++++++++++++------------------------------
drivers/siox/siox-core.c | 46 ++++++++++++++++++++++++++++++++
drivers/siox/siox.h | 4 +++
3 files changed, 70 insertions(+), 42 deletions(-)
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Hello Greg,
[Cc += Linus]
On Fri, Mar 08, 2024 at 10:20:05PM +0100, Uwe Kleine-K?nig wrote:
> On Thu, Mar 07, 2024 at 09:38:07AM +0100, Uwe Kleine-K?nig wrote:
> > On Thu, Mar 07, 2024 at 07:29:59AM +0000, Greg Kroah-Hartman wrote:
> > > Can you send me a "real" git pull request so that I can verify it is
> > > what you say it is (ideally with a signed tag)?
> >
> > Sure, can do. I will do that tomorrow when (and if) my branch is in next
> > and so got a bit more exposure.
>
> That has worked so far. So here comes the requested pull request. I
> dropped the two patches you collected in the meantime in your
> char-misc-next branch. The two branches (i.e. your char-misc-next and
> this PR's tag) merge without conflict.
>
> The following changes since commit 6613476e225e090cc9aad49be7fa504e290dd33d:
>
> Linux 6.8-rc1 (2024-01-21 14:11:32 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git tags/siox/for-greg-6.9-rc1
>
> for you to fetch changes up to db418d5f1ca5b7bafc8eaa9393ea18a7901bb0ed:
>
> siox: bus-gpio: Simplify using devm_siox_* functions (2024-03-08 22:01:10 +0100)
>
> Please pull this for the 6.9-rc1 merge window.
I didn't hear anything back from you and wonder if there is still a
chance to get this in. I guess that's just you being busy with other
(and more important) stuff. Would it help you if I sent a pull request
to Linus directly?
The changes are in next leading to db418d5f1ca5 since next-20240308. (As
db418d5f1ca since next-20240312, I rebased as two of the six siox
patches got into char-misc-next that were picked up directly from the
mailing list. Before the rebase it was 4ab973203404.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Hello Greg,
On Sat, Mar 16, 2024 at 08:37:04AM +0100, Uwe Kleine-K?nig wrote:
> On Fri, Mar 08, 2024 at 10:20:05PM +0100, Uwe Kleine-K?nig wrote:
> > On Thu, Mar 07, 2024 at 09:38:07AM +0100, Uwe Kleine-K?nig wrote:
> > > On Thu, Mar 07, 2024 at 07:29:59AM +0000, Greg Kroah-Hartman wrote:
> > > > Can you send me a "real" git pull request so that I can verify it is
> > > > what you say it is (ideally with a signed tag)?
> > >
> > > Sure, can do. I will do that tomorrow when (and if) my branch is in next
> > > and so got a bit more exposure.
> >
> > That has worked so far. So here comes the requested pull request. I
> > dropped the two patches you collected in the meantime in your
> > char-misc-next branch. The two branches (i.e. your char-misc-next and
> > this PR's tag) merge without conflict.
> >
> > The following changes since commit 6613476e225e090cc9aad49be7fa504e290dd33d:
> >
> > Linux 6.8-rc1 (2024-01-21 14:11:32 -0800)
> >
> > are available in the Git repository at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git tags/siox/for-greg-6.9-rc1
> >
> > for you to fetch changes up to db418d5f1ca5b7bafc8eaa9393ea18a7901bb0ed:
> >
> > siox: bus-gpio: Simplify using devm_siox_* functions (2024-03-08 22:01:10 +0100)
> >
> > Please pull this for the 6.9-rc1 merge window.
>
> I didn't hear anything back from you and wonder if there is still a
> chance to get this in. I guess that's just you being busy with other
> (and more important) stuff. Would it help you if I sent a pull request
> to Linus directly?
>
> The changes are in next leading to db418d5f1ca5 since next-20240308. (As
> db418d5f1ca since next-20240312, I rebased as two of the six siox
> patches got into char-misc-next that were picked up directly from the
> mailing list. Before the rebase it was 4ab973203404.)
You probably saw me being impatient and sending the PR to Linus
directly. If not: These changes are already in the mainline now
(00453419575d6b4f5ce0f370da9421cf5253f103) and this is the thread you
can drop from your todo list. I removed the above tag from my repository
to (hopefully) prevent future confusion.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On Fri, Mar 22, 2024 at 08:22:16AM +0100, Uwe Kleine-K?nig wrote:
> Hello Greg,
>
> On Sat, Mar 16, 2024 at 08:37:04AM +0100, Uwe Kleine-K?nig wrote:
> > On Fri, Mar 08, 2024 at 10:20:05PM +0100, Uwe Kleine-K?nig wrote:
> > > On Thu, Mar 07, 2024 at 09:38:07AM +0100, Uwe Kleine-K?nig wrote:
> > > > On Thu, Mar 07, 2024 at 07:29:59AM +0000, Greg Kroah-Hartman wrote:
> > > > > Can you send me a "real" git pull request so that I can verify it is
> > > > > what you say it is (ideally with a signed tag)?
> > > >
> > > > Sure, can do. I will do that tomorrow when (and if) my branch is in next
> > > > and so got a bit more exposure.
> > >
> > > That has worked so far. So here comes the requested pull request. I
> > > dropped the two patches you collected in the meantime in your
> > > char-misc-next branch. The two branches (i.e. your char-misc-next and
> > > this PR's tag) merge without conflict.
> > >
> > > The following changes since commit 6613476e225e090cc9aad49be7fa504e290dd33d:
> > >
> > > Linux 6.8-rc1 (2024-01-21 14:11:32 -0800)
> > >
> > > are available in the Git repository at:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git tags/siox/for-greg-6.9-rc1
> > >
> > > for you to fetch changes up to db418d5f1ca5b7bafc8eaa9393ea18a7901bb0ed:
> > >
> > > siox: bus-gpio: Simplify using devm_siox_* functions (2024-03-08 22:01:10 +0100)
> > >
> > > Please pull this for the 6.9-rc1 merge window.
> >
> > I didn't hear anything back from you and wonder if there is still a
> > chance to get this in. I guess that's just you being busy with other
> > (and more important) stuff. Would it help you if I sent a pull request
> > to Linus directly?
> >
> > The changes are in next leading to db418d5f1ca5 since next-20240308. (As
> > db418d5f1ca since next-20240312, I rebased as two of the six siox
> > patches got into char-misc-next that were picked up directly from the
> > mailing list. Before the rebase it was 4ab973203404.)
>
> You probably saw me being impatient and sending the PR to Linus
> directly. If not: These changes are already in the mainline now
> (00453419575d6b4f5ce0f370da9421cf5253f103) and this is the thread you
> can drop from your todo list. I removed the above tag from my repository
> to (hopefully) prevent future confusion.
No worries, I see this is all in Linus's tree. Sorry for the delay, I
was actually on vacation for once and didn't have the chance to do all
of this (and to be fair, you asked for the pull request way too late...)
thanks,
greg k-h
Hey Greg,
On Fri, Mar 22, 2024 at 08:31:15AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 22, 2024 at 08:22:16AM +0100, Uwe Kleine-K?nig wrote:
> > You probably saw me being impatient and sending the PR to Linus
> > directly. If not: These changes are already in the mainline now
> > (00453419575d6b4f5ce0f370da9421cf5253f103) and this is the thread you
> > can drop from your todo list. I removed the above tag from my repository
> > to (hopefully) prevent future confusion.
>
> No worries, I see this is all in Linus's tree. Sorry for the delay, I
> was actually on vacation for once and didn't have the chance to do all
> of this
No need to be sorry. There are no hard feelings on my side. It's
important for indiviuals and also for the project that key persons are
not available at times.
> (and to be fair, you asked for the pull request way too late...)
I sent the pull request the day following you requesting it. If the
timing is so tight, a note about that would be helpful. (No offence
intended!)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |