Message ID | ZFI74eeUzVPKhi4f@matsya |
---|---|
State | Accepted |
Commit | 54bdf8a39931cf8fe2c74432e715353d9a1c1107 |
Headers | show |
Series | [GIT,PULL] : Generic phy updates for v6.4 | expand |
The pull request you sent on Wed, 3 May 2023 16:18:01 +0530:
> git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git tags/phy-for-6.4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/54bdf8a39931cf8fe2c74432e715353d9a1c1107
Thank you!
Hi Vinod, On Wed, May 03, 2023 at 04:18:01PM +0530, Vinod Koul wrote: > Hello Linus, > > Please consider pull to receive generic phy updates for v6.4-rc1. We > have a bunch of new controller support in qcom, mediatek and rk socs. > Intel Thunder Bay eMMC PHY driver is dropped as no users and bunch of > driver updates for the subsystem > > The following changes since commit fe15c26ee26efa11741a7b632e9f23b01aca4cc6: > > Linux 6.3-rc1 (2023-03-05 14:52:03 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git tags/phy-for-6.4 > > for you to fetch changes up to a0106132372120dd0abf5ad7636614e5aeb5da08: > > phy: cadence: cdns-dphy-rx: Add common module reset support (2023-04-12 22:16:16 +0530) > > ---------------------------------------------------------------- > phy-for-6.4 > > - New support: > - UFS PHY for Qualcomm SA8775p, SM7150 > - PCIe 2 lane phy support for sc8180x and PCIe PHY for SDX65 > - Mediatke hdmi phy support for mt8195 > - rockchip naneng combo phy support for RK358 > > - Updates: > - Drop Thunder Bay eMMC PHY driver > - RC support for PCIe phy for Qualcomm SDX55 > - SGMII support in WIZ driver for J721E > - PCIe and multilink SGMII PHY support in cadence driver > - Big pile of platform remove callback returning void conversions > > ---------------------------------------------------------------- ... > Guillaume Ranquet (3): > dt-bindings: phy: mediatek: hdmi-phy: Add mt8195 compatible > phy: phy-mtk-hdmi: Add generic phy configure callback > phy: mediatek: add support for phy-mtk-hdmi-mt8195 This patch went in without one of the three simple/obvious fixes sent to you, so now clang builds with -Werror are broken, as they have been in -next for almost three weeks :/ https://lore.kernel.org/20230413-fixes-for-mt8195-hdmi-phy-v2-1-bbad62e64321@baylibre.com/ https://lore.kernel.org/20230414075842.4006164-1-arnd@kernel.org/ https://lore.kernel.org/20230414122253.3171524-1-trix@redhat.com/ drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: error: variable 'ret' is uninitialized when used here [-Werror,-Wuninitialized] if (ret) ^~~ drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:216:12: note: initialize the variable 'ret' to silence this warning int i, ret; ^ = 0 1 error generated. Could one of these please be picked up by either you or Linus directly, since this is the third ping on the matter: https://lore.kernel.org/20230421221330.GA3657732@dev-arch.thelio-3990X/ https://lore.kernel.org/CAKwvOd=5szkx5yA0bxcyktx85opAwLrB3_4n13SMV7p3m9x7LQ@mail.gmail.com/ Cheers, Nathan
On 04-05-23, 08:06, Nathan Chancellor wrote: > Hi Vinod, > > On Wed, May 03, 2023 at 04:18:01PM +0530, Vinod Koul wrote: > > Hello Linus, > > > > Please consider pull to receive generic phy updates for v6.4-rc1. We > > have a bunch of new controller support in qcom, mediatek and rk socs. > > Intel Thunder Bay eMMC PHY driver is dropped as no users and bunch of > > driver updates for the subsystem > > > > The following changes since commit fe15c26ee26efa11741a7b632e9f23b01aca4cc6: > > > > Linux 6.3-rc1 (2023-03-05 14:52:03 -0800) > > > > are available in the Git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git tags/phy-for-6.4 > > > > for you to fetch changes up to a0106132372120dd0abf5ad7636614e5aeb5da08: > > > > phy: cadence: cdns-dphy-rx: Add common module reset support (2023-04-12 22:16:16 +0530) > > > > ---------------------------------------------------------------- > > phy-for-6.4 > > > > - New support: > > - UFS PHY for Qualcomm SA8775p, SM7150 > > - PCIe 2 lane phy support for sc8180x and PCIe PHY for SDX65 > > - Mediatke hdmi phy support for mt8195 > > - rockchip naneng combo phy support for RK358 > > > > - Updates: > > - Drop Thunder Bay eMMC PHY driver > > - RC support for PCIe phy for Qualcomm SDX55 > > - SGMII support in WIZ driver for J721E > > - PCIe and multilink SGMII PHY support in cadence driver > > - Big pile of platform remove callback returning void conversions > > > > ---------------------------------------------------------------- > ... > > Guillaume Ranquet (3): > > dt-bindings: phy: mediatek: hdmi-phy: Add mt8195 compatible > > phy: phy-mtk-hdmi: Add generic phy configure callback > > phy: mediatek: add support for phy-mtk-hdmi-mt8195 > > This patch went in without one of the three simple/obvious fixes sent to > you, so now clang builds with -Werror are broken, as they have been in > -next for almost three weeks :/ Sorry between vacation and travel, this was missed. No worries we have process to deal with this, so this shall go in as fixes.. I will do the needful shortly Thanks
On Thu, May 4, 2023 at 8:31 AM Vinod Koul <vkoul@kernel.org> wrote: > Sorry between vacation and travel, this was missed. > > No worries we have process to deal with this, so this shall go in as > fixes.. I will do the needful shortly You need to do it *now*. You should never have sent the pull request to me in the first place if you hadn't checked the status in linux-next. The point of linux-next is to find failures. And if you don't then *care* about the failures, then it has all become entirely pointless, and it's effectively the same as if it had never been there in the first place. So this needs to get fixed *PRONTO*, and it needs to never ever happen again. Because if it does happen, I will consider your code to effectively never have been in linux-next, and thus just not be an option for pulling. This isn't debatable. You don't put things in linux-next, ignore the reports, and then send things upstream anyway. If you don't have time to check the status of your tree in linux-next, you don't have the time to do a pull request. That's just how it works. Linus
On 04-05-23, 10:23, Linus Torvalds wrote: > On Thu, May 4, 2023 at 8:31 AM Vinod Koul <vkoul@kernel.org> wrote: > > Sorry between vacation and travel, this was missed. > > > > No worries we have process to deal with this, so this shall go in as > > fixes.. I will do the needful shortly > > You need to do it *now*. It was already done a bit ago and applied to my fixes and should be in -next tomorrow. I will wait a day before sending you fixes update. > You should never have sent the pull request to me in the first place > if you hadn't checked the status in linux-next. > > The point of linux-next is to find failures. And if you don't then > *care* about the failures, then it has all become entirely pointless, > and it's effectively the same as if it had never been there in the > first place. > > So this needs to get fixed *PRONTO*, and it needs to never ever happen again. Ack, agree I should have paid it more attention. Between vacation and travel and stuff I have missed it this time, will ensure this doesn't happen again. > > Because if it does happen, I will consider your code to effectively > never have been in linux-next, and thus just not be an option for > pulling. > > This isn't debatable. You don't put things in linux-next, ignore the > reports, and then send things upstream anyway. > > If you don't have time to check the status of your tree in linux-next, > you don't have the time to do a pull request. That's just how it > works. > > Linus