The :export: keyword makes sense only for C-files, where EXPORT_SYMBOL()
might appear. Otherwise kernel-doc may not produce anything out of this
file.
Reported-by: Stephen Rothwell <[email protected]>
Fixes: f97fa3dcb2db ("lib/math: Move dvb_math.c into lib/math/int_log.c")
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Acked-by: Jonathan Corbet <[email protected]>
---
v2: added tags (Randy, Jonathan), assumed to go via ASoC tree
Documentation/core-api/kernel-api.rst | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst
index a526fbe06f86..ae92a2571388 100644
--- a/Documentation/core-api/kernel-api.rst
+++ b/Documentation/core-api/kernel-api.rst
@@ -166,7 +166,6 @@ Integer log and power Functions
-------------------------------
.. kernel-doc:: include/linux/int_log.h
- :export:
.. kernel-doc:: lib/math/int_pow.c
:export:
--
2.40.0.1.gaa8946217a0b
Andy Shevchenko <[email protected]> writes:
> The :export: keyword makes sense only for C-files, where EXPORT_SYMBOL()
> might appear. Otherwise kernel-doc may not produce anything out of this
> file.
>
> Reported-by: Stephen Rothwell <[email protected]>
> Fixes: f97fa3dcb2db ("lib/math: Move dvb_math.c into lib/math/int_log.c")
> Signed-off-by: Andy Shevchenko <[email protected]>
> Reviewed-by: Randy Dunlap <[email protected]>
> Acked-by: Jonathan Corbet <[email protected]>
> ---
> v2: added tags (Randy, Jonathan), assumed to go via ASoC tree
> Documentation/core-api/kernel-api.rst | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst
> index a526fbe06f86..ae92a2571388 100644
> --- a/Documentation/core-api/kernel-api.rst
> +++ b/Documentation/core-api/kernel-api.rst
> @@ -166,7 +166,6 @@ Integer log and power Functions
> -------------------------------
>
> .. kernel-doc:: include/linux/int_log.h
> - :export:
>
So I still can't take this patch for the reasons described before. It
looks like Mark took the patch that added the problem, so perhaps he
should be a recipient of this one too? I'll add him to the CC...
jon
On Tue, Jul 25, 2023 at 07:12:25AM -0600, Jonathan Corbet wrote:
> Andy Shevchenko <[email protected]> writes:
> > The :export: keyword makes sense only for C-files, where EXPORT_SYMBOL()
> > might appear. Otherwise kernel-doc may not produce anything out of this
> > file.
> So I still can't take this patch for the reasons described before. It
> looks like Mark took the patch that added the problem, so perhaps he
> should be a recipient of this one too? I'll add him to the CC...
Is this the same patch I applied yesterday or a different one?
On Tue, Jul 25, 2023 at 02:46:33PM +0100, Mark Brown wrote:
> On Tue, Jul 25, 2023 at 07:12:25AM -0600, Jonathan Corbet wrote:
> > Andy Shevchenko <[email protected]> writes:
>
> > > The :export: keyword makes sense only for C-files, where EXPORT_SYMBOL()
> > > might appear. Otherwise kernel-doc may not produce anything out of this
> > > file.
>
> > So I still can't take this patch for the reasons described before. It
> > looks like Mark took the patch that added the problem, so perhaps he
> > should be a recipient of this one too? I'll add him to the CC...
>
> Is this the same patch I applied yesterday or a different one?
Hmm...
I do not see anything like this patch in your current ASoC for-next
(nor in for-6.6). Did I look into wrong branch?
--
With Best Regards,
Andy Shevchenko
On Tue, Jul 25, 2023 at 07:12:25AM -0600, Jonathan Corbet wrote:
> Andy Shevchenko <[email protected]> writes:
> > ---
> > v2: added tags (Randy, Jonathan), assumed to go via ASoC tree
> So I still can't take this patch for the reasons described before. It
> looks like Mark took the patch that added the problem, so perhaps he
> should be a recipient of this one too?
That's what have been assumed above.
> I'll add him to the CC...
Oh, I missed Cc'ing him...
--
With Best Regards,
Andy Shevchenko
On Tue, Jul 25, 2023 at 05:06:30PM +0300, Andy Shevchenko wrote:
> On Tue, Jul 25, 2023 at 02:46:33PM +0100, Mark Brown wrote:
> > Is this the same patch I applied yesterday or a different one?
> Hmm...
> I do not see anything like this patch in your current ASoC for-next
> (nor in for-6.6). Did I look into wrong branch?
There was some random patch you just sent me the message ID for in the
replies to something from Stephen which I'm fairly sure I queued,
perhaps it was a different thing or git thought it was a noop when it
was applied?
On Tue, Jul 25, 2023 at 05:40:54PM +0300, Andy Shevchenko wrote:
> On Tue, Jul 25, 2023 at 03:27:58PM +0100, Mark Brown wrote:
> > There was some random patch you just sent me the message ID for in the
> > replies to something from Stephen which I'm fairly sure I queued,
> > perhaps it was a different thing or git thought it was a noop when it
> > was applied?
> The first version is here [1].
> Then it was a discussion about Linux Next build issues [2].
> In the discussion I mentioned:
> The [email protected] had been sent.
> which is exactly what [1] is.
> I have no idea how it can be a noop, but the patch is missing as far
> as I can tell.
> This thread is v2 of what was in [1].
> [1]: https://lore.kernel.org/linux-doc/[email protected]/
> [2]: https://lore.kernel.org/linux-next/[email protected]/T/#u
So there's two versions of the patch and for some reason v1 was
mentioned yesterday but there's also a v2 version?
On Tue, Jul 25, 2023 at 03:27:58PM +0100, Mark Brown wrote:
> On Tue, Jul 25, 2023 at 05:06:30PM +0300, Andy Shevchenko wrote:
> > On Tue, Jul 25, 2023 at 02:46:33PM +0100, Mark Brown wrote:
>
> > > Is this the same patch I applied yesterday or a different one?
>
> > Hmm...
> > I do not see anything like this patch in your current ASoC for-next
> > (nor in for-6.6). Did I look into wrong branch?
>
> There was some random patch you just sent me the message ID for in the
> replies to something from Stephen which I'm fairly sure I queued,
> perhaps it was a different thing or git thought it was a noop when it
> was applied?
The first version is here [1].
Then it was a discussion about Linux Next build issues [2].
In the discussion I mentioned:
The [email protected] had been sent.
which is exactly what [1] is.
I have no idea how it can be a noop, but the patch is missing as far
as I can tell.
This thread is v2 of what was in [1].
[1]: https://lore.kernel.org/linux-doc/[email protected]/
[2]: https://lore.kernel.org/linux-next/[email protected]/T/#u
--
With Best Regards,
Andy Shevchenko
On Tue, Jul 25, 2023 at 03:51:44PM +0100, Mark Brown wrote:
> On Tue, Jul 25, 2023 at 05:40:54PM +0300, Andy Shevchenko wrote:
> > On Tue, Jul 25, 2023 at 03:27:58PM +0100, Mark Brown wrote:
>
> > > There was some random patch you just sent me the message ID for in the
> > > replies to something from Stephen which I'm fairly sure I queued,
> > > perhaps it was a different thing or git thought it was a noop when it
> > > was applied?
>
> > The first version is here [1].
> > Then it was a discussion about Linux Next build issues [2].
>
> > In the discussion I mentioned:
>
> > The [email protected] had been sent.
>
> > which is exactly what [1] is.
>
> > I have no idea how it can be a noop, but the patch is missing as far
> > as I can tell.
>
> > This thread is v2 of what was in [1].
>
> > [1]: https://lore.kernel.org/linux-doc/[email protected]/
> > [2]: https://lore.kernel.org/linux-next/[email protected]/T/#u
>
> So there's two versions of the patch and for some reason v1 was
> mentioned yesterday but there's also a v2 version?
Yes, and I forgot to initially Cc you for v2.
If you are using b4, you can take Message ID of this message and I am sure it
capable to retrieve v2 of the patch. Or I can resend with you in Cc list.
--
With Best Regards,
Andy Shevchenko
On Tue, 25 Jul 2023 13:49:56 +0300, Andy Shevchenko wrote:
> The :export: keyword makes sense only for C-files, where EXPORT_SYMBOL()
> might appear. Otherwise kernel-doc may not produce anything out of this
> file.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] Documentation: core-api: Drop :export: for int_log.h
commit: 5bdeb6f5c7b94f653183f08eca8a08022b2efac6
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
On Tue, Jul 25, 2023 at 08:20:32PM +0100, Mark Brown wrote:
> On Tue, 25 Jul 2023 13:49:56 +0300, Andy Shevchenko wrote:
> > The :export: keyword makes sense only for C-files, where EXPORT_SYMBOL()
> > might appear. Otherwise kernel-doc may not produce anything out of this
> > file.
>
> Applied to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
>
> Thanks!
Thank you!
--
With Best Regards,
Andy Shevchenko