On Wed, 10 Apr 2024 16:02:00 +0200 Julien Panis wrote:
> > You shouldn't build the skb upfront any more. Give the page to the HW,
> > once HW sends you a completion - build the skbs. If build fails
> > (allocation failure) just give the page back to HW. If it succeeds,
> > however, you'll get a skb which is far more likely to be cache hot.
>
> Not sure I get this point.
>
> "Give the page to the HW" = Do you mean that I should dma_map_single()
> a full page (|PAGE_SIZE|) in am65_cpsw_nuss_rx_push() ?
Yes, I think so. I think that's what you effectively do now anyway,
you just limit the len and wrap it in an skb. But
am65_cpsw_nuss_rx_push() will effectively get that page back from
skb->data and map it.
On Wed, 10 Apr 2024 10:36:16 +0200 Julien Panis wrote:
> Also, about mem alloc failures, shouldn't we free 'pool' on kstrdup_const()
> error at the beginning of k3_cppi_desc_pool_create_name() ?
> I mean, it's not visible in my patch but I now wonder if this was done
> properly even before I modify the file.
Yes, it uses managed memory (devm_*) but prueth (I didn't check other
callers) calls it from .ndo_open. So while not technically a full leak
we can accumulate infinite memory by repeatedly failing here :S
On Mon, 08 Apr 2024 11:38:04 +0200 Julien Panis wrote:
> +static struct sk_buff *am65_cpsw_alloc_skb(struct am65_cpsw_rx_chn *rx_chn,
> + struct net_device *ndev,
> + unsigned int len,
> + int desc_idx,
> + bool allow_direct)
> +{
> + struct sk_buff *skb;
> + struct page *page;
> +
> + page = page_pool_dev_alloc_pages(rx_chn->page_pool);
> + if (unlikely(!page))
> + return NULL;
> +
> + len += AM65_CPSW_HEADROOM;
> +
> + skb = build_skb(page_address(page), len);
You shouldn't build the skb upfront any more. Give the page to the HW,
once HW sends you a completion - build the skbs. If build fails
(allocation failure) just give the page back to HW. If it succeeds,
however, you'll get a skb which is far more likely to be cache hot.
> + if (unlikely(!skb)) {
> + page_pool_put_full_page(rx_chn->page_pool, page, allow_direct);
> + rx_chn->pages[desc_idx] = NULL;
> + return NULL;
> + }
On Mon, 08 Apr 2024 11:38:03 +0200 Julien Panis wrote:
> goto gen_pool_create_fail;
> }
>
> + pool->desc_infos = kcalloc(pool->num_desc,
> + sizeof(*pool->desc_infos), GFP_KERNEL);
> + if (!pool->desc_infos) {
> + ret = -ENOMEM;
> + dev_err(pool->dev,
> + "pool descriptor infos alloc failed %d\n", ret);
Please don't add errors on mem alloc failures. They just bloat the
kernel, there will be a rather large OOM splat in the logs if GFP_KERNEL
allocation fails.
> + kfree_const(pool_name);
> + goto gen_pool_desc_infos_alloc_fail;
> + }
> +
> pool->gen_pool->name = pool_name;
If you add the new allocation after this line, I think you wouldn't
have to free pool_name under the if () explicitly.
--
pw-bot: cr
On 09/04/2024 15:42, Alexandre Mergnat wrote:
> Add the audio codec sub-device. This sub-device is used to set required
> and optional voltage properties between the codec and the board.
>
> Signed-off-by: Alexandre Mergnat <amergnat(a)baylibre.com>
> ---
> Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml
> index 37423c2e0fdf..7c6a4a587b5f 100644
> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml
> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml
> @@ -37,6 +37,11 @@ properties:
> "#interrupt-cells":
> const: 2
>
> + codec:
> + type: object
> + $ref: /schemas/sound/mt6357.yaml
> + unevaluatedProperties: false
Just put the properties here, without the codec node.
Also, your example is now incomplete.
Best regards,
Krzysztof
On 09/04/2024 15:42, Alexandre Mergnat wrote:
> Add soundcard bindings for the MT8365 SoC with the MT6357 audio codec.
>
> Signed-off-by: Alexandre Mergnat <amergnat(a)baylibre.com>
> +patternProperties:
> + "^dai-link-[0-9]+$":
> + type: object
> + description:
> + Container for dai-link level properties and CODEC sub-nodes.
> +
> + properties:
> + codec:
> + type: object
> + description: Holds subnode which indicates codec dai.
> +
> + properties:
> + sound-dai:
> + maxItems: 1
> + description: phandle of the codec DAI
> +
> + additionalProperties: false
> +
> + link-name:
> + description:
> + This property corresponds to the name of the BE dai-link to which
> + we are going to update parameters in this node.
> + items:
> + const: 2ND_I2S_BE
What is the type of link-name? Why is it fixed? How can you have here
multiple dai links if all of them must have the same name?
Best regards,
Krzysztof