* [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe @ 2024-11-06 22:33 Karol Przybylski 2024-11-06 23:03 ` Shuah Khan 2024-11-06 23:15 ` Andreas Kemnade 0 siblings, 2 replies; 8+ messages in thread From: Karol Przybylski @ 2024-11-06 22:33 UTC (permalink / raw) To: aaro.koskinen, andreas, khilman, rogerq, tony, lee, karprzy7 Cc: linux-omap, linux-kernel, skhan clk_prepare() is called in usbtll_omap_probe to fill clk array. Return code is not checked, leaving possible error condition unhandled. Added variable to hold return value from clk_prepare() and return statement when it's not successful. Found in coverity scan, CID 1594680 Signed-off-by: Karol Przybylski <karprzy7@gmail.com> --- drivers/mfd/omap-usb-tll.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c index 0f7fdb99c809..28446b082c85 100644 --- a/drivers/mfd/omap-usb-tll.c +++ b/drivers/mfd/omap-usb-tll.c @@ -202,7 +202,7 @@ static int usbtll_omap_probe(struct platform_device *pdev) struct device *dev = &pdev->dev; struct usbtll_omap *tll; void __iomem *base; - int i, nch, ver; + int i, nch, ver, err; dev_dbg(dev, "starting TI HSUSB TLL Controller\n"); @@ -251,7 +251,11 @@ static int usbtll_omap_probe(struct platform_device *pdev) if (IS_ERR(tll->ch_clk[i])) dev_dbg(dev, "can't get clock : %s\n", clkname); else - clk_prepare(tll->ch_clk[i]); + err = clk_prepare(tll->ch_clk[i]); + if (err) { + dev_err(dev, "Unable to prepare clock\n"); + return err; + } } pm_runtime_put_sync(dev); -- 2.34.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe 2024-11-06 22:33 [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe Karol Przybylski @ 2024-11-06 23:03 ` Shuah Khan 2024-11-06 23:15 ` Andreas Kemnade 1 sibling, 0 replies; 8+ messages in thread From: Shuah Khan @ 2024-11-06 23:03 UTC (permalink / raw) To: Karol Przybylski, aaro.koskinen, andreas, khilman, rogerq, tony, lee Cc: linux-omap, linux-kernel, Shuah Khan On 11/6/24 15:33, Karol Przybylski wrote: > clk_prepare() is called in usbtll_omap_probe to fill clk array. > Return code is not checked, leaving possible error condition unhandled. > > Added variable to hold return value from clk_prepare() and return statement > when it's not successful. > > Found in coverity scan, CID 1594680 > > Signed-off-by: Karol Przybylski <karprzy7@gmail.com> > --- > drivers/mfd/omap-usb-tll.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c > index 0f7fdb99c809..28446b082c85 100644 > --- a/drivers/mfd/omap-usb-tll.c > +++ b/drivers/mfd/omap-usb-tll.c > @@ -202,7 +202,7 @@ static int usbtll_omap_probe(struct platform_device *pdev) > struct device *dev = &pdev->dev; > struct usbtll_omap *tll; > void __iomem *base; > - int i, nch, ver; > + int i, nch, ver, err; > > dev_dbg(dev, "starting TI HSUSB TLL Controller\n"); > > @@ -251,7 +251,11 @@ static int usbtll_omap_probe(struct platform_device *pdev) > if (IS_ERR(tll->ch_clk[i])) > dev_dbg(dev, "can't get clock : %s\n", clkname); > else > - clk_prepare(tll->ch_clk[i]); Braces for the conditional don't looks right. > + err = clk_prepare(tll->ch_clk[i]); > + if (err) { > + dev_err(dev, "Unable to prepare clock\n"); > + return err; Did you check to see if callers handle this new error return in this path? > + } Same here > } > Same here > pm_runtime_put_sync(dev); thanks, -- Shuah ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe 2024-11-06 22:33 [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe Karol Przybylski 2024-11-06 23:03 ` Shuah Khan @ 2024-11-06 23:15 ` Andreas Kemnade 2024-11-07 11:12 ` Karol P 1 sibling, 1 reply; 8+ messages in thread From: Andreas Kemnade @ 2024-11-06 23:15 UTC (permalink / raw) To: Karol Przybylski Cc: aaro.koskinen, khilman, rogerq, tony, lee, linux-omap, linux-kernel, skhan Am Wed, 6 Nov 2024 23:33:24 +0100 schrieb Karol Przybylski <karprzy7@gmail.com>: > clk_prepare() is called in usbtll_omap_probe to fill clk array. > Return code is not checked, leaving possible error condition unhandled. > > Added variable to hold return value from clk_prepare() and return statement > when it's not successful. > > Found in coverity scan, CID 1594680 > > Signed-off-by: Karol Przybylski <karprzy7@gmail.com> > --- > drivers/mfd/omap-usb-tll.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c > index 0f7fdb99c809..28446b082c85 100644 > --- a/drivers/mfd/omap-usb-tll.c > +++ b/drivers/mfd/omap-usb-tll.c > @@ -202,7 +202,7 @@ static int usbtll_omap_probe(struct platform_device *pdev) > struct device *dev = &pdev->dev; > struct usbtll_omap *tll; > void __iomem *base; > - int i, nch, ver; > + int i, nch, ver, err; > > dev_dbg(dev, "starting TI HSUSB TLL Controller\n"); > > @@ -251,7 +251,11 @@ static int usbtll_omap_probe(struct platform_device *pdev) > if (IS_ERR(tll->ch_clk[i])) > dev_dbg(dev, "can't get clock : %s\n", clkname); if you add more intensive error checking, then why is this error ignored and not returned? > else > - clk_prepare(tll->ch_clk[i]); > + err = clk_prepare(tll->ch_clk[i]); > + if (err) { unnatural braces, if (err) is not in the else branch ?! > + dev_err(dev, "Unable to prepare clock\n"); > + return err; > + } > } > > pm_runtime_put_sync(dev); and this one is not called if you return early. Regards, Andreas ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe 2024-11-06 23:15 ` Andreas Kemnade @ 2024-11-07 11:12 ` Karol P 2024-11-09 23:29 ` Andreas Kemnade 0 siblings, 1 reply; 8+ messages in thread From: Karol P @ 2024-11-07 11:12 UTC (permalink / raw) To: Andreas Kemnade Cc: aaro.koskinen, khilman, rogerq, tony, lee, linux-omap, linux-kernel, skhan On Thu, 7 Nov 2024 at 00:15, Andreas Kemnade <andreas@kemnade.info> wrote: > > Am Wed, 6 Nov 2024 23:33:24 +0100 > schrieb Karol Przybylski <karprzy7@gmail.com>: > > > clk_prepare() is called in usbtll_omap_probe to fill clk array. > > Return code is not checked, leaving possible error condition unhandled. > > > > Added variable to hold return value from clk_prepare() and return statement > > when it's not successful. > > > > Found in coverity scan, CID 1594680 > > > > Signed-off-by: Karol Przybylski <karprzy7@gmail.com> > > --- > > drivers/mfd/omap-usb-tll.c | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c > > index 0f7fdb99c809..28446b082c85 100644 > > --- a/drivers/mfd/omap-usb-tll.c > > +++ b/drivers/mfd/omap-usb-tll.c > > @@ -202,7 +202,7 @@ static int usbtll_omap_probe(struct platform_device *pdev) > > struct device *dev = &pdev->dev; > > struct usbtll_omap *tll; > > void __iomem *base; > > - int i, nch, ver; > > + int i, nch, ver, err; > > > > dev_dbg(dev, "starting TI HSUSB TLL Controller\n"); > > > > @@ -251,7 +251,11 @@ static int usbtll_omap_probe(struct platform_device *pdev) > > if (IS_ERR(tll->ch_clk[i])) > > dev_dbg(dev, "can't get clock : %s\n", clkname); > > if you add more intensive error checking, then why is this error > ignored and not returned? Thank you for the feedback. It does seem that elevated error checking is not the way to go in this case. Do you think it would be good to add a similar statement instead of my initial changes? It would look something like this: + else { err = clk_prepare(tll->ch_clk[i]); + if (err) + dev_dbg(dev, "clock prepare error for: %s\n", clkname); + } > > > else > > - clk_prepare(tll->ch_clk[i]); > > + err = clk_prepare(tll->ch_clk[i]); > > + if (err) { > unnatural braces, if (err) is not in the else branch ?! > > + dev_err(dev, "Unable to prepare clock\n"); > > + return err; > > + } > > } > > > > pm_runtime_put_sync(dev); > and this one is not called if you return early. > > Regards, > Andreas ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe 2024-11-07 11:12 ` Karol P @ 2024-11-09 23:29 ` Andreas Kemnade 2024-11-11 14:41 ` Roger Quadros 0 siblings, 1 reply; 8+ messages in thread From: Andreas Kemnade @ 2024-11-09 23:29 UTC (permalink / raw) To: Karol P Cc: aaro.koskinen, khilman, rogerq, tony, lee, linux-omap, linux-kernel, skhan Am Thu, 7 Nov 2024 12:12:52 +0100 schrieb Karol P <karprzy7@gmail.com>: > On Thu, 7 Nov 2024 at 00:15, Andreas Kemnade <andreas@kemnade.info> wrote: > > > > Am Wed, 6 Nov 2024 23:33:24 +0100 > > schrieb Karol Przybylski <karprzy7@gmail.com>: > > > > > clk_prepare() is called in usbtll_omap_probe to fill clk array. > > > Return code is not checked, leaving possible error condition unhandled. > > > > > > Added variable to hold return value from clk_prepare() and return statement > > > when it's not successful. > > > > > > Found in coverity scan, CID 1594680 > > > > > > Signed-off-by: Karol Przybylski <karprzy7@gmail.com> > > > --- > > > drivers/mfd/omap-usb-tll.c | 8 ++++++-- > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c > > > index 0f7fdb99c809..28446b082c85 100644 > > > --- a/drivers/mfd/omap-usb-tll.c > > > +++ b/drivers/mfd/omap-usb-tll.c > > > @@ -202,7 +202,7 @@ static int usbtll_omap_probe(struct platform_device *pdev) > > > struct device *dev = &pdev->dev; > > > struct usbtll_omap *tll; > > > void __iomem *base; > > > - int i, nch, ver; > > > + int i, nch, ver, err; > > > > > > dev_dbg(dev, "starting TI HSUSB TLL Controller\n"); > > > > > > @@ -251,7 +251,11 @@ static int usbtll_omap_probe(struct platform_device *pdev) > > > if (IS_ERR(tll->ch_clk[i])) > > > dev_dbg(dev, "can't get clock : %s\n", clkname); > > > > if you add more intensive error checking, then why is this error > > ignored and not returned? > > Thank you for the feedback. It does seem that elevated error checking > is not the way > to go in this case. As far as I can see everything checks ch_clk[i] for validity before usage. Also clk_enable() called later is checked which would catch clk_prepare() failures, if there were even possible here. So the only question which I am not 100% sure about is whether having ch_clk sparsly populated is normal operation. If that is the case, then more error checking is not useful. If not, then it might let us better sleep. As said as far as I can see errors are catched later. @Roger: what is your opintion towards this? BTW: If you do this kind of work, you could also use W=1 or CONFIG_WERROR during compiling to catch easy things. At least I see new compile warnings with your patch. Regards, Andreas ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe 2024-11-09 23:29 ` Andreas Kemnade @ 2024-11-11 14:41 ` Roger Quadros 2024-11-11 19:57 ` Andreas Kemnade 0 siblings, 1 reply; 8+ messages in thread From: Roger Quadros @ 2024-11-11 14:41 UTC (permalink / raw) To: Andreas Kemnade, Karol P Cc: aaro.koskinen, khilman, tony, lee, linux-omap, linux-kernel, skhan Hi, On 10/11/2024 01:29, Andreas Kemnade wrote: > Am Thu, 7 Nov 2024 12:12:52 +0100 > schrieb Karol P <karprzy7@gmail.com>: > >> On Thu, 7 Nov 2024 at 00:15, Andreas Kemnade <andreas@kemnade.info> wrote: >>> >>> Am Wed, 6 Nov 2024 23:33:24 +0100 >>> schrieb Karol Przybylski <karprzy7@gmail.com>: >>> >>>> clk_prepare() is called in usbtll_omap_probe to fill clk array. >>>> Return code is not checked, leaving possible error condition unhandled. >>>> >>>> Added variable to hold return value from clk_prepare() and return statement >>>> when it's not successful. >>>> >>>> Found in coverity scan, CID 1594680 >>>> >>>> Signed-off-by: Karol Przybylski <karprzy7@gmail.com> >>>> --- >>>> drivers/mfd/omap-usb-tll.c | 8 ++++++-- >>>> 1 file changed, 6 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c >>>> index 0f7fdb99c809..28446b082c85 100644 >>>> --- a/drivers/mfd/omap-usb-tll.c >>>> +++ b/drivers/mfd/omap-usb-tll.c >>>> @@ -202,7 +202,7 @@ static int usbtll_omap_probe(struct platform_device *pdev) >>>> struct device *dev = &pdev->dev; >>>> struct usbtll_omap *tll; >>>> void __iomem *base; >>>> - int i, nch, ver; >>>> + int i, nch, ver, err; >>>> >>>> dev_dbg(dev, "starting TI HSUSB TLL Controller\n"); >>>> >>>> @@ -251,7 +251,11 @@ static int usbtll_omap_probe(struct platform_device *pdev) >>>> if (IS_ERR(tll->ch_clk[i])) >>>> dev_dbg(dev, "can't get clock : %s\n", clkname); >>> >>> if you add more intensive error checking, then why is this error >>> ignored and not returned? >> >> Thank you for the feedback. It does seem that elevated error checking >> is not the way >> to go in this case. > > As far as I can see everything checks ch_clk[i] for validity before > usage. Also clk_enable() called later is checked which would catch > clk_prepare() failures, if there were even possible here. > > So the only question which I am not 100% sure about is whether having > ch_clk sparsly populated is normal operation. If that is the case, then > more error checking is not useful. If not, then it might let us better > sleep. As said as far as I can see errors are catched later. > > @Roger: what is your opintion towards this? I don't see usb_tll_hs_usb_ch?_clk in any of the OMAP device trees. Could it be that they are optional? If so then we could convert it to devm_clk_get_optional()? While at that, maybe the device tree binding could also be updated and converted to yaml. > > BTW: If you do this kind of work, you could also use W=1 or > CONFIG_WERROR during compiling to catch easy things. At least I see new > compile warnings with your patch. > > Regards, > Andreas -- cheers, -roger ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe 2024-11-11 14:41 ` Roger Quadros @ 2024-11-11 19:57 ` Andreas Kemnade 2024-11-12 11:59 ` Karol P 0 siblings, 1 reply; 8+ messages in thread From: Andreas Kemnade @ 2024-11-11 19:57 UTC (permalink / raw) To: Roger Quadros Cc: Karol P, aaro.koskinen, khilman, tony, lee, linux-omap, linux-kernel, skhan Am Mon, 11 Nov 2024 16:41:47 +0200 schrieb Roger Quadros <rogerq@kernel.org>: > Hi, > > On 10/11/2024 01:29, Andreas Kemnade wrote: > > Am Thu, 7 Nov 2024 12:12:52 +0100 > > schrieb Karol P <karprzy7@gmail.com>: > > > >> On Thu, 7 Nov 2024 at 00:15, Andreas Kemnade <andreas@kemnade.info> wrote: > >>> > >>> Am Wed, 6 Nov 2024 23:33:24 +0100 > >>> schrieb Karol Przybylski <karprzy7@gmail.com>: > >>> > >>>> clk_prepare() is called in usbtll_omap_probe to fill clk array. > >>>> Return code is not checked, leaving possible error condition unhandled. > >>>> > >>>> Added variable to hold return value from clk_prepare() and return statement > >>>> when it's not successful. > >>>> > >>>> Found in coverity scan, CID 1594680 > >>>> > >>>> Signed-off-by: Karol Przybylski <karprzy7@gmail.com> > >>>> --- > >>>> drivers/mfd/omap-usb-tll.c | 8 ++++++-- > >>>> 1 file changed, 6 insertions(+), 2 deletions(-) > >>>> > >>>> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c > >>>> index 0f7fdb99c809..28446b082c85 100644 > >>>> --- a/drivers/mfd/omap-usb-tll.c > >>>> +++ b/drivers/mfd/omap-usb-tll.c > >>>> @@ -202,7 +202,7 @@ static int usbtll_omap_probe(struct platform_device *pdev) > >>>> struct device *dev = &pdev->dev; > >>>> struct usbtll_omap *tll; > >>>> void __iomem *base; > >>>> - int i, nch, ver; > >>>> + int i, nch, ver, err; > >>>> > >>>> dev_dbg(dev, "starting TI HSUSB TLL Controller\n"); > >>>> > >>>> @@ -251,7 +251,11 @@ static int usbtll_omap_probe(struct platform_device *pdev) > >>>> if (IS_ERR(tll->ch_clk[i])) > >>>> dev_dbg(dev, "can't get clock : %s\n", clkname); > >>> > >>> if you add more intensive error checking, then why is this error > >>> ignored and not returned? > >> > >> Thank you for the feedback. It does seem that elevated error checking > >> is not the way > >> to go in this case. > > > > As far as I can see everything checks ch_clk[i] for validity before > > usage. Also clk_enable() called later is checked which would catch > > clk_prepare() failures, if there were even possible here. > > > > So the only question which I am not 100% sure about is whether having > > ch_clk sparsly populated is normal operation. If that is the case, then > > more error checking is not useful. If not, then it might let us better > > sleep. As said as far as I can see errors are catched later. > > > > @Roger: what is your opintion towards this? > > I don't see usb_tll_hs_usb_ch?_clk in any of the OMAP device trees. > Could it be that they are optional? > If so then we could convert it to devm_clk_get_optional()? > They live in drivers/clk/ti/clk-[54]4xx.c But nothing about omap3. So apparently we can have valid use cases where these clocks are not available. So no real need more anything more than dev_dbg output here. Regards, Andreas ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe 2024-11-11 19:57 ` Andreas Kemnade @ 2024-11-12 11:59 ` Karol P 0 siblings, 0 replies; 8+ messages in thread From: Karol P @ 2024-11-12 11:59 UTC (permalink / raw) To: Andreas Kemnade Cc: Roger Quadros, aaro.koskinen, khilman, tony, lee, linux-omap, linux-kernel, skhan On Mon, 11 Nov 2024 at 20:57, Andreas Kemnade <andreas@kemnade.info> wrote: > > Am Mon, 11 Nov 2024 16:41:47 +0200 > schrieb Roger Quadros <rogerq@kernel.org>: > > > Hi, > > > > On 10/11/2024 01:29, Andreas Kemnade wrote: > > > Am Thu, 7 Nov 2024 12:12:52 +0100 > > > schrieb Karol P <karprzy7@gmail.com>: > > > > > >> On Thu, 7 Nov 2024 at 00:15, Andreas Kemnade <andreas@kemnade.info> wrote: > > >>> > > >>> Am Wed, 6 Nov 2024 23:33:24 +0100 > > >>> schrieb Karol Przybylski <karprzy7@gmail.com>: > > >>> > > >>>> clk_prepare() is called in usbtll_omap_probe to fill clk array. > > >>>> Return code is not checked, leaving possible error condition unhandled. > > >>>> > > >>>> Added variable to hold return value from clk_prepare() and return statement > > >>>> when it's not successful. > > >>>> > > >>>> Found in coverity scan, CID 1594680 > > >>>> > > >>>> Signed-off-by: Karol Przybylski <karprzy7@gmail.com> > > >>>> --- > > >>>> drivers/mfd/omap-usb-tll.c | 8 ++++++-- > > >>>> 1 file changed, 6 insertions(+), 2 deletions(-) > > >>>> > > >>>> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c > > >>>> index 0f7fdb99c809..28446b082c85 100644 > > >>>> --- a/drivers/mfd/omap-usb-tll.c > > >>>> +++ b/drivers/mfd/omap-usb-tll.c > > >>>> @@ -202,7 +202,7 @@ static int usbtll_omap_probe(struct platform_device *pdev) > > >>>> struct device *dev = &pdev->dev; > > >>>> struct usbtll_omap *tll; > > >>>> void __iomem *base; > > >>>> - int i, nch, ver; > > >>>> + int i, nch, ver, err; > > >>>> > > >>>> dev_dbg(dev, "starting TI HSUSB TLL Controller\n"); > > >>>> > > >>>> @@ -251,7 +251,11 @@ static int usbtll_omap_probe(struct platform_device *pdev) > > >>>> if (IS_ERR(tll->ch_clk[i])) > > >>>> dev_dbg(dev, "can't get clock : %s\n", clkname); > > >>> > > >>> if you add more intensive error checking, then why is this error > > >>> ignored and not returned? > > >> > > >> Thank you for the feedback. It does seem that elevated error checking > > >> is not the way > > >> to go in this case. > > > > > > As far as I can see everything checks ch_clk[i] for validity before > > > usage. Also clk_enable() called later is checked which would catch > > > clk_prepare() failures, if there were even possible here. > > > > > > So the only question which I am not 100% sure about is whether having > > > ch_clk sparsly populated is normal operation. If that is the case, then > > > more error checking is not useful. If not, then it might let us better > > > sleep. As said as far as I can see errors are catched later. > > > > > > @Roger: what is your opintion towards this? > > > > I don't see usb_tll_hs_usb_ch?_clk in any of the OMAP device trees. > > Could it be that they are optional? > > If so then we could convert it to devm_clk_get_optional()? > > > They live in drivers/clk/ti/clk-[54]4xx.c > But nothing about omap3. So apparently we can have valid use cases > where these clocks are not available. So no real need more anything > more than dev_dbg output here. > > Regards, > Andreas Thanks, I will send in a new patch then. I can also take a look at updating device tree binding. Best regards, Karol ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-11-12 11:59 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-11-06 22:33 [PATCH] mfd: omap-usb-tll: handle clk_prepare return code in usbtll_omap_probe Karol Przybylski 2024-11-06 23:03 ` Shuah Khan 2024-11-06 23:15 ` Andreas Kemnade 2024-11-07 11:12 ` Karol P 2024-11-09 23:29 ` Andreas Kemnade 2024-11-11 14:41 ` Roger Quadros 2024-11-11 19:57 ` Andreas Kemnade 2024-11-12 11:59 ` Karol P
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox