Cover Letter Detail
Show a cover letter.
GET /api/1.0/covers/2219257/?format=api
{ "id": 2219257, "url": "http://patchwork.ozlabs.org/api/1.0/covers/2219257/?format=api", "project": { "id": 21, "url": "http://patchwork.ozlabs.org/api/1.0/projects/21/?format=api", "name": "Linux Tegra Development", "link_name": "linux-tegra", "list_id": "linux-tegra.vger.kernel.org", "list_email": "linux-tegra@vger.kernel.org", "web_url": null, "scm_url": null, "webscm_url": null }, "msgid": "<20260402170641.2082547-1-joonwonkang@google.com>", "date": "2026-04-02T17:06:39", "name": "[v3,0/2] mailbox: Fix wrong completion order and improper send result in the blocking mode send API", "submitter": { "id": 91088, "url": "http://patchwork.ozlabs.org/api/1.0/people/91088/?format=api", "name": "Joonwon Kang", "email": "joonwonkang@google.com" }, "series": [ { "id": 498517, "url": "http://patchwork.ozlabs.org/api/1.0/series/498517/?format=api", "date": "2026-04-02T17:06:41", "name": "mailbox: Fix wrong completion order and improper send result in the blocking mode send API", "version": 3, "mbox": "http://patchwork.ozlabs.org/series/498517/mbox/" } ], "headers": { "Return-Path": "\n <linux-tegra+bounces-13541-incoming=patchwork.ozlabs.org@vger.kernel.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "linux-tegra@vger.kernel.org" ], "Delivered-To": "patchwork-incoming@legolas.ozlabs.org", "Authentication-Results": [ "legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256\n header.s=20251104 header.b=NI41NAY3;\n\tdkim-atps=neutral", "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=104.64.211.4; helo=sin.lore.kernel.org;\n envelope-from=linux-tegra+bounces-13541-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)", "smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=google.com header.i=@google.com\n header.b=\"NI41NAY3\"", "smtp.subspace.kernel.org;\n arc=none smtp.client-ip=209.85.214.202", "smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=google.com", "smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=flex--joonwonkang.bounces.google.com" ], "Received": [ "from sin.lore.kernel.org (sin.lore.kernel.org [104.64.211.4])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fmpTy3D4tz1yCs\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 03 Apr 2026 04:18:30 +1100 (AEDT)", "from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id B084F306E005\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 2 Apr 2026 17:07:11 +0000 (UTC)", "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 34AD2371055;\n\tThu, 2 Apr 2026 17:07:11 +0000 (UTC)", "from mail-pl1-f202.google.com (mail-pl1-f202.google.com\n [209.85.214.202])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 6F4B13ECBDD\n\tfor <linux-tegra@vger.kernel.org>; Thu, 2 Apr 2026 17:07:00 +0000 (UTC)", "by mail-pl1-f202.google.com with SMTP id\n d9443c01a7336-2b249975139so25712575ad.0\n for <linux-tegra@vger.kernel.org>;\n Thu, 02 Apr 2026 10:07:00 -0700 (PDT)" ], "ARC-Seal": "i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775149629; cv=none;\n b=PRUScpNy32SiuvQsEAqKsk9lkOIgt8LoiZmsWG1bD+DPEYDy6qAfsAw2G9b8Rzlqk64dUyf6yHupCFe88m1crNxAXBWUGYiCCET8Cfpde54HkO9gaXwc7xva/nFmV5t0MpHF1qVyfMeHXnI49A6V2+4fGttxQJUc+kxuJggNjHY=", "ARC-Message-Signature": "i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775149629; c=relaxed/simple;\n\tbh=pjCqOLmJ4hu1XzDffMUDURIAFvHzh4g7TG3XafIlPn8=;\n\th=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type;\n b=aj0qP5Ctgkra5wQZvRtTFkyln3RnSE41RpJsifsCM5loQj9Hxm8B6m9giOftYMByPKrwg6fnsddESIB6vOV8b6pxePStkg58DBKo9M38A+csJBhEX+W3pACe6X+MeRN9TAaC3FzF3l4fLojSw8xVBNjhXsWmkYxyj/m7R8Oa3xA=", "ARC-Authentication-Results": "i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=reject dis=none) header.from=google.com;\n spf=pass smtp.mailfrom=flex--joonwonkang.bounces.google.com;\n dkim=pass (2048-bit key) header.d=google.com header.i=@google.com\n header.b=NI41NAY3; arc=none smtp.client-ip=209.85.214.202", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=google.com; s=20251104; t=1775149619; x=1775754419;\n darn=vger.kernel.org;\n h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject\n :date:message-id:reply-to;\n bh=5ceebF0cNoevtXZxXS/tupzteUV9Qk2AK74OlrZ5xNE=;\n b=NI41NAY3v8ioJHB/zaJecieiy4H8OpVGK2LSHQ80ZVdcIKp0hxo+8ZSOegWMZBCdGJ\n hb5PFeIg06tczKyeK+TmDkkVYfVh4DCJUR/BRwuGtNv9avMPuwE/chjpc2wYMNfkmU0V\n 10w0aSbbXARE9XNuDJ2txcnWFkl9Z+KJGP5uwJEbTK8oRNhcXtUHzMt8iJzSV2LldD7s\n VyJeQ/0Pi/MmzXzQJcf0K2uZfn/UxELhzBBMFg99lPFakULQbD/Q4/h5RfQLc1iRma6J\n CtTiJcCnZ8k7oM2LOvJJ7/+MGN8ymDF3/c97fkhStHPSQtW/tdP2cnY24d5Wpad0z1QJ\n MlBQ==", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775149619; x=1775754419;\n h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state\n :from:to:cc:subject:date:message-id:reply-to;\n bh=5ceebF0cNoevtXZxXS/tupzteUV9Qk2AK74OlrZ5xNE=;\n b=GYQcvVKC6CCp7vEuQdYvuyzMjjc1IZFAhoe3mLWe9W3wRmJt7H95DNQfYSN+tNCfw4\n YaDb1+wAdQx798V97cDbyDMqGNyc3xiGmAoQ2kDJKGFXTM68XYKXFMy/tqwxmdjPUHtY\n Mj5AJf5aRbhd4+aQB8kTRDc6DNpUxZwALKRuvqotx2tCS6RVLch+7tZ0gfeQkiayfJ2l\n yHHJzDiPGPeAge4zuLkkp3R7UBb/dqihDZLiuylnoOkaH1b4bOb20msIffsuaalylZRS\n FLfdbw9GUiJlzWCOPkTLf4rEkM1V6OHJ6NVVBYn6KMVr6FMcshX32+yC95bTPRZ+8Mw+\n frNw==", "X-Forwarded-Encrypted": "i=1;\n AJvYcCUf64zH/Qz7mpVIDPc5tBRVxP9jCOjA/E5mDjcSfBFxTwfaWcNhdlJVHz6+IoFirLz1aLNrMvn/nQAt0w==@vger.kernel.org", "X-Gm-Message-State": "AOJu0YxTDUxwYqh0Jka/FxASwMwAukyqLBa4W8k/sTGrvbb3HYs5ukAt\n\tAotxus4G/wzbX+o+30o70XGbv4c5V50J7I69AMulPKc3QK7AWCm0hNzwwL0RNbfjzKpUvg828U4\n\tCeebSZAeNOoKLY4NuqIUUU8oJgg==", "X-Received": "from ploe7.prod.google.com ([2002:a17:903:2407:b0:2b0:b03a:16ce])\n (user=joonwonkang job=prod-delivery.src-stubby-dispatcher) by\n 2002:a17:903:3d0f:b0:2b2:4cd2:e174 with SMTP id\n d9443c01a7336-2b281811ef1mr573475ad.43.1775149618937;\n Thu, 02 Apr 2026 10:06:58 -0700 (PDT)", "Date": "Thu, 2 Apr 2026 17:06:39 +0000", "Precedence": "bulk", "X-Mailing-List": "linux-tegra@vger.kernel.org", "List-Id": "<linux-tegra.vger.kernel.org>", "List-Subscribe": "<mailto:linux-tegra+subscribe@vger.kernel.org>", "List-Unsubscribe": "<mailto:linux-tegra+unsubscribe@vger.kernel.org>", "Mime-Version": "1.0", "X-Mailer": "git-send-email 2.53.0.1213.gd9a14994de-goog", "Message-ID": "<20260402170641.2082547-1-joonwonkang@google.com>", "Subject": "[PATCH v3 0/2] mailbox: Fix wrong completion order and improper send\n result in the blocking mode send API", "From": "Joonwon Kang <joonwonkang@google.com>", "To": "jassisinghbrar@gmail.com, matthias.bgg@gmail.com,\n\tangelogioacchino.delregno@collabora.com, thierry.reding@gmail.com,\n\tjonathanh@nvidia.com", "Cc": "linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,\n\tlinux-mediatek@lists.infradead.org, linux-tegra@vger.kernel.org,\n\tJoonwon Kang <joonwonkang@google.com>", "Content-Type": "text/plain; charset=\"UTF-8\"" }, "content": "Hi team,\n\nThis patch series fixes the two major issues in blocking mode.\n\n1) Wrong completion order in the send API as described in [1]:\n\n Thread#1(T1) Thread#2(T2)\n mbox_send_message mbox_send_message\n | |\n V |\n add_to_rbuf(M1) V\n | add_to_rbuf(M2)\n | |\n | V\n V msg_submit(picks M1)\n msg_submit |\n | V\n V wait_for_completion(on M2)\n wait_for_completion(on M1) | (1st in waitQ)\n | (2nd in waitQ) V\n V wake_up(on completion of M1)<--incorrect\n\n2) Send API does not return the actual send result.\n\nThis patch series contains two patches for each issue:\n 0001-mailbox-Use-per-thread-completion-to-fix-wrong-co.patch\n 0002-mailbox-Make-mbox_send_message-return-error-code-.patch\n\nThe first issue has to do with multi-threads support. Given the\ndiscussion in [1] with the mailbox framework maintainer, it has been\nlong thought that the mailbox framework is designed to support\nmulti-threads although it missed the completion order issue at its\nintroduction. The first patch of this series is to fix it.\n\nAlternatively, we could instead declare that the mailbox API does not\nsupport multi-threads [2]. However, it would be a sudden big change to\nthe mailbox users after the long standing implication of supporting\nmulti-threads. Plus, it would have disparity with the non-blocking mode\nwhich supports multi-threads already, which could also lead to confusion\nto the users by saying \"non-blocking mode supports multi-threads whereas\nblocking mode doesn't\". For this reason, the first patch in this series\ndoes not choose this alternative.\n\nThe patch series rules out the case where tx_tick() is called twice or\nmore for a sent message on the same channel. In theory, it could happen\nwhen timeout occurs. For example, one tx_tick() by the mailbox core due\nto timeout and another tx_tick() by the mailbox controller or client by\naccident or for any other reason. If it happens, the internal mailbox\nstate could become inconsistent even on a single thread. Thus, this\nissue should be handled in an orthogonal effort later on.\n\nThe second issue forces users to register tx done callback to get the\nactual send result although they are using the blocking mode send API.\nThis behavior is different from typical blocking send APIs, which just\nreturn the actual send result directly, and so confusing to the users.\nWithout knowing this additional requirement of the API, it would be\nprone to miss the send result check entirely. The second patch is to fix\nit by making the blocking mode send API return the actual send result.\n\nChange log of the first patch:\n - v3: Rebase on the latest for-next branch.\n - v2: Consider the case where timeout occurs and so tx_tick() is called\n for a channel by one thread while another thread is having an active\n request on the same channel. In that case, we mark the inactive\n request as canceled and do not send it to the controller.\n - v1: The previous solution in v0 tries to have per-message completion:\n `tx_cmpl[MBOX_TX_QUEUE_LEN]`; each completion belongs to each slot of\n the message queue: `msg_data[i]`. Those completions take up additional\n memory even when they are not used. Instead, this patch tries to have\n per-\"thread\" completion; each completion belongs to each sender thread\n and each slot of the message queue has a pointer to that completion;\n `struct mbox_message` has the \"pointer\" field\n `struct completion *tx_complete` which points to the completion which\n is created on the stack of the sender, instead of owning the\n completion by `struct completion tx_complete`. This way, we could\n avoid additional memory use since a completion will be allocated only\n when necessary. Plus, more importantly, we could avoid the window\n where the same completion is reused by different sender threads, which\n the previous solution still has.\n - v0: This first attempt tries to have per-message completion: [1].\n\nChange log of the second patch:\n - No major change from v1.\n\nReferences:\n - [1]: https://lore.kernel.org/all/1490809381-28869-1-git-send-email-jaswinder.singh@linaro.org\n - [2]: https://lore.kernel.org/all/CABb+yY39rhTZbtA21MecYk-R9fh7VQQr5kZUgCw4z92mWhZ1Rg@mail.gmail.com/\n\n\nJoonwon Kang (2):\n mailbox: Use per-thread completion to fix wrong completion order\n mailbox: Make mbox_send_message() return error code when tx fails\n\n drivers/mailbox/mailbox.c | 98 ++++++++++++++++++++----------\n drivers/mailbox/mtk-vcp-mailbox.c | 2 +-\n drivers/mailbox/tegra-hsp.c | 2 +-\n include/linux/mailbox_controller.h | 22 +++++--\n 4 files changed, 85 insertions(+), 39 deletions(-)\n\n\nThanks,\nJoonwon Kang" }