[PATCH 03/16] staging: m57621-mmc: delete driver from the tree.
The license text in this driver is "interesting" and not really obvious
that it is supposed to be able to be distributed in the kernel source
tree. Yes, the MODULE_LICENSE() text says GPL, so it's probably ok, but
to be safe, I am deleting this driver. I will be glad to add it back if
the license is properly sorted out, but for now, this isn't worth the
potential risk, I should have never taken it in the first place.
Cc: Matthias Brugger
Cc: NeilBrown
Cc: George Hilliard
Cc: "Christian Lütke-Stetzkamp"
Cc: Nishad Kamdar
Cc: Sergej Perschin
Cc: John Crispin
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/Kconfig|2 -
drivers/staging/Makefile |1 -
drivers/staging/mt7621-mmc/Kconfig |9 -
drivers/staging/mt7621-mmc/Makefile| 42 -
drivers/staging/mt7621-mmc/TODO|8 -
drivers/staging/mt7621-mmc/board.h | 63 -
drivers/staging/mt7621-mmc/dbg.c | 311
drivers/staging/mt7621-mmc/dbg.h | 106 --
drivers/staging/mt7621-mmc/mt6575_sd.h | 485 ---
drivers/staging/mt7621-mmc/sd.c| 1859
10 files changed, 2886 deletions(-)
delete mode 100644 drivers/staging/mt7621-mmc/Kconfig
delete mode 100644 drivers/staging/mt7621-mmc/Makefile
delete mode 100644 drivers/staging/mt7621-mmc/TODO
delete mode 100644 drivers/staging/mt7621-mmc/board.h
delete mode 100644 drivers/staging/mt7621-mmc/dbg.c
delete mode 100644 drivers/staging/mt7621-mmc/dbg.h
delete mode 100644 drivers/staging/mt7621-mmc/mt6575_sd.h
delete mode 100644 drivers/staging/mt7621-mmc/sd.c
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 37121f495cd7..6319369cca89 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -113,8 +113,6 @@ source "drivers/staging/mt7621-dma/Kconfig"
source "drivers/staging/ralink-gdma/Kconfig"
-source "drivers/staging/mt7621-mmc/Kconfig"
-
source "drivers/staging/mt7621-dts/Kconfig"
source "drivers/staging/gasket/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index d1b17ddcd354..763d18f56b10 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -46,7 +46,6 @@ obj-$(CONFIG_PINCTRL_RT2880) += mt7621-pinctrl/
obj-$(CONFIG_SPI_MT7621) += mt7621-spi/
obj-$(CONFIG_SOC_MT7621) += mt7621-dma/
obj-$(CONFIG_DMA_RALINK) += ralink-gdma/
-obj-$(CONFIG_MTK_MMC) += mt7621-mmc/
obj-$(CONFIG_SOC_MT7621) += mt7621-dts/
obj-$(CONFIG_STAGING_GASKET_FRAMEWORK) += gasket/
obj-$(CONFIG_XIL_AXIS_FIFO)+= axis-fifo/
diff --git a/drivers/staging/mt7621-mmc/Kconfig
b/drivers/staging/mt7621-mmc/Kconfig
deleted file mode 100644
index 6ede50e9ddc0..
--- a/drivers/staging/mt7621-mmc/Kconfig
+++ /dev/null
@@ -1,9 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-config MTK_MMC
- tristate "MTK SD/MMC"
- depends on RALINK && MMC
-
-config MTK_AEE_KDUMP
- bool "MTK AEE KDUMP"
- depends on MTK_MMC
-
diff --git a/drivers/staging/mt7621-mmc/Makefile
b/drivers/staging/mt7621-mmc/Makefile
deleted file mode 100644
index caead0b54703..
--- a/drivers/staging/mt7621-mmc/Makefile
+++ /dev/null
@@ -1,42 +0,0 @@
-# Copyright Statement:
-#
-# This software/firmware and related documentation ("MediaTek Software") are
-# protected under relevant copyright laws. The information contained herein
-# is confidential and proprietary to MediaTek Inc. and/or its licensors.
-# Without the prior written permission of MediaTek inc. and/or its licensors,
-# any reproduction, modification, use or disclosure of MediaTek Software,
-# and information contained herein, in whole or in part, shall be strictly
prohibited.
-#
-# MediaTek Inc. (C) 2010. All rights reserved.
-#
-# BY OPENING THIS FILE, RECEIVER HEREBY UNEQUIVOCALLY ACKNOWLEDGES AND AGREES
-# THAT THE SOFTWARE/FIRMWARE AND ITS DOCUMENTATIONS ("MEDIATEK SOFTWARE")
-# RECEIVED FROM MEDIATEK AND/OR ITS REPRESENTATIVES ARE PROVIDED TO RECEIVER ON
-# AN "AS-IS" BASIS ONLY. MEDIATEK EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES,
-# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
-# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT.
-# NEITHER DOES MEDIATEK PROVIDE ANY WARRANTY WHATSOEVER WITH RESPECT TO THE
-# SOFTWARE OF ANY THIRD PARTY WHICH MAY BE USED BY, INCORPORATED IN, OR
-# SUPPLIED WITH THE MEDIATEK SOFTWARE, AND RECEIVER AGREES TO LOOK ONLY TO SUCH
-# THIRD PARTY FOR ANY WARRANTY CLAIM RELATING THERETO. RECEIVER EXPRESSLY
ACKNOWLEDGES
-# THAT IT IS RECEIVER'S SOLE RESPONSIBILITY TO OBTAIN FROM ANY THIRD PARTY ALL
PROPER LICENSES
-# CONTAINED IN MEDIATEK SOFTWARE. MEDIATEK SHALL ALSO NOT BE RESPONSIBLE FOR
ANY MEDIATEK
-# SOFTWARE RELEASES MADE TO RECEIVER'S SPECIFICATION OR TO CONFORM TO A
PARTICULAR
-# STANDARD OR OPEN FORUM. RECEIVER'S SOLE AND EXCLUSIVE REMEDY AND MEDIATEK'S
ENTIRE AND
-# CUMULATIVE LIABILITY WITH RESPECT TO THE MEDIATEK SOFTWARE RELEASED
HEREUN
Re: [PATCH 03/16] staging: m57621-mmc: delete driver from the tree.
On Tue, Apr 02, 2019 at 06:16:47AM -0500, George Hilliard wrote: > On Tue, Apr 2, 2019, 5:32 AM Greg Kroah-Hartman > wrote: > > > The license text in this driver is "interesting" and not really obvious > > that it is supposed to be able to be distributed in the kernel source > > tree. Yes, the MODULE_LICENSE() text says GPL, so it's probably ok, but > > to be safe, I am deleting this driver. I will be glad to add it back if > > the license is properly sorted out, but for now, this isn't worth the > > potential risk, I should have never taken it in the first place. > > > > So, for what it's worth, this driver has an obvious heritage of having been > modified from the main Mediatek MMC driver. Now, of course it's *possible* > to distribute GPL-incompatible changes to a GPL program, but the only > *compliant* way to distribute these changes would have been the GPL. > > So there's a very good chance that it's intended to be GPL. (Which is > good, because I need this driver!) I suppose we need to reach out to the > original contributor. I agree that the intent is probably GPL, especially given the MODULE_LICENSE string, and in general how mediatek handles their kernel code (they properly opensource it all.) I think that someone got a little bit "heavy handed" on the comment blocks at the top of all of these files though, and that is what makes this whole thing questionable and needs to be addressed. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/16] staging: m57621-mmc: delete driver from the tree.
On Tue, Apr 02 2019, George Hilliard wrote: > On Tue, Apr 2, 2019, 5:32 AM Greg Kroah-Hartman > wrote: > >> The license text in this driver is "interesting" and not really obvious >> that it is supposed to be able to be distributed in the kernel source >> tree. Yes, the MODULE_LICENSE() text says GPL, so it's probably ok, but >> to be safe, I am deleting this driver. I will be glad to add it back if >> the license is properly sorted out, but for now, this isn't worth the >> potential risk, I should have never taken it in the first place. >> > > So, for what it's worth, this driver has an obvious heritage of having been > modified from the main Mediatek MMC driver. Now, of course it's *possible* > to distribute GPL-incompatible changes to a GPL program, but the only > *compliant* way to distribute these changes would have been the GPL. > > So there's a very good chance that it's intended to be GPL. (Which is > good, because I need this driver!) I suppose we need to reach out to the > original contributor. People keep telling me that drivers/mmc/host/mtk-sd.c should be able to handle the same hardware as this driver, with a little bit of work. Unfortunately they haven't told me what the little bit of work involves. Have you explored that possibility at all? I might try to have a look if I can make time. NeilBrown signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/16] staging: m57621-mmc: delete driver from the tree.
On Wed, Apr 03, 2019 at 06:51:49AM +1100, NeilBrown wrote: > People keep telling me that drivers/mmc/host/mtk-sd.c should be able to > handle the same hardware as this driver, with a little bit of work. > Unfortunately they haven't told me what the little bit of work involves. > > Have you explored that possibility at all? I might try to have a look > if I can make time. I have started to look into it, when I was working on that driver. First sorry for me doing nothing in the last few month. Generally the two drivers seem to be very similar, the main difference is the code for tuning. In the staging driver. this is a total mess. It tries to account for tuning itself, so it also tries to account which command was executed (succesfully) before a tuning is necessary and reexecutes it, when it was the APP_CMD. But there are still some differences in the tuning code, that are not due to handling it in the driver. If have mainly understand how to remove the 'in driver handling' of the tuning and thing I could prepare a patch for that. But the differences in the tuning code itself, I do not understand completely. There are two other larger differences that I found during my work. One is that drivers/mmc/host/mtk-sd.c has much more features, like voltage and clock handling and some support for high speed modes. I don't know if these features are required/useful for this device. The other thing is the card detect handling. This driver is doing the card detect / read only detection on its own, where the in tree one just uses some default gpio functions there and I don't know weather this must be changed or weather there is a gpio driver for the mt7621. That is all I currently remember. Hope it helps. Christian ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/16] staging: m57621-mmc: delete driver from the tree.
On Tue, Apr 02 2019, Christian Lütke-Stetzkamp wrote: > On Wed, Apr 03, 2019 at 06:51:49AM +1100, NeilBrown wrote: >> People keep telling me that drivers/mmc/host/mtk-sd.c should be able to >> handle the same hardware as this driver, with a little bit of work. >> Unfortunately they haven't told me what the little bit of work involves. >> >> Have you explored that possibility at all? I might try to have a look >> if I can make time. > > I have started to look into it, when I was working on that > driver. First sorry for me doing nothing in the last few > month. Generally the two drivers seem to be very similar, the main > difference is the code for tuning. In the staging driver. this is a > total mess. It tries to account for tuning itself, so it also tries to > account which command was executed (succesfully) before a tuning is > necessary and reexecutes it, when it was the APP_CMD. But there are > still some differences in the tuning code, that are not due to > handling it in the driver. > > If have mainly understand how to remove the 'in driver handling' of > the tuning and thing I could prepare a patch for that. But the > differences in the tuning code itself, I do not understand > completely. > > There are two other larger differences that I found during my > work. One is that drivers/mmc/host/mtk-sd.c has much more features, > like voltage and clock handling and some support for high speed > modes. I don't know if these features are required/useful for this > device. The other thing is the card detect handling. This driver is > doing the card detect / read only detection on its own, where the in > tree one just uses some default gpio functions there and I don't know > weather this must be changed or weather there is a gpio driver for the > mt7621. > > That is all I currently remember. Hope it helps. > > Christian Thanks, it might be. Other info I have received at https://github.com/gnubee-git/GnuBee_Docs/issues/75#issuecomment-479216537 is that there might be something worth examining at https://github.com/jonpry/openwrt_mt7688/commit/a85e6d99899f3dc1204cd5bfba944e17bfa6178f https://github.com/jonpry/openwrt_mt7688/commit/24878467a650d765b747618de1a575e79114b764 A few notes: The MMC driver there is basically the 4.9 mtk-sd one with all the patches from maybe 4.17 or 4.18 backported. and that a diff against current mainline here: https://gist.github.com/neheb/3d9e4cbf966f8487114df19b49f28214 might be useful. I'll look more on the weekend if no-one beats me to it. NeilBrown signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/16] staging: m57621-mmc: delete driver from the tree.
On Tue, Apr 2, 2019 at 3:45 PM Christian Lütke-Stetzkamp wrote: > There are two other larger differences that I found during my > work. One is that drivers/mmc/host/mtk-sd.c has much more features, > like voltage and clock handling and some support for high speed > modes. I don't know if these features are required/useful for this > device. For what it's worth, I found an old forum post of someone who was dealing with a crashy kernel on their mt7688. They removed the mt7621-mmc driver and hacked the clock code out of the mainline driver. Apparently it worked. I never got around to duplicating their work, however. (I too ran into severe instability problems with the mt7621-mmc driver, but they only appeared in conjunction with using the SLOB allocator. I could never debug it because when JTAG was turned on, the SDMC peripheral was disabled for some reason I never discovered. More info on that if someone is interested.) The correct way to do this would be to have a "compatible" flag that bypassed the clock handling code. I don't think there are any relevant clocks to set up on the MT7628/MT7688 - the MSDC peripheral does not appear in the clock plan. > The other thing is the card detect handling. This driver is > doing the card detect / read only detection on its own, where the in > tree one just uses some default gpio functions there and I don't know > weather this must be changed or weather there is a gpio driver for the > mt7621. There is a "mtk,mt7621-gpio"-compatible GPIO driver available. Probably it would work with GPIO on new hardware that did not to route CD to the CD pin, because the CD pin is muxed using the same "SD card" pin state as the SD data pins. I do not know if it is possible for the GPIO peripheral to read the pin while it is muxed to the SD controller, as would be necessary for existing hardware. George ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/16] staging: m57621-mmc: delete driver from the tree.
On Wed, Apr 03 2019, George Hilliard wrote:
> On Tue, Apr 2, 2019 at 3:45 PM Christian Lütke-Stetzkamp
> wrote:
>> There are two other larger differences that I found during my
>> work. One is that drivers/mmc/host/mtk-sd.c has much more features,
>> like voltage and clock handling and some support for high speed
>> modes. I don't know if these features are required/useful for this
>> device.
>
> For what it's worth, I found an old forum post of someone who was
> dealing with a crashy kernel on their mt7688. They removed the
> mt7621-mmc driver and hacked the clock code out of the mainline
> driver. Apparently it worked. I never got around to duplicating
> their work, however. (I too ran into severe instability problems with
> the mt7621-mmc driver, but they only appeared in conjunction with
> using the SLOB allocator. I could never debug it because when JTAG
> was turned on, the SDMC peripheral was disabled for some reason I
> never discovered. More info on that if someone is interested.)
>
> The correct way to do this would be to have a "compatible" flag that
> bypassed the clock handling code. I don't think there are any
> relevant clocks to set up on the MT7628/MT7688 - the MSDC peripheral
> does not appear in the clock plan.
>
>> The other thing is the card detect handling. This driver is
>> doing the card detect / read only detection on its own, where the in
>> tree one just uses some default gpio functions there and I don't know
>> weather this must be changed or weather there is a gpio driver for the
>> mt7621.
>
> There is a "mtk,mt7621-gpio"-compatible GPIO driver available.
> Probably it would work with GPIO on new hardware that did not to route
> CD to the CD pin, because the CD pin is muxed using the same "SD card"
> pin state as the SD data pins. I do not know if it is possible for
> the GPIO peripheral to read the pin while it is muxed to the SD
> controller, as would be necessary for existing hardware.
>
> George
FYI I have mmc working on my mt7621 board using the
drivers/mmc/host/mtk_sd.c driver and the following patch.
I haven't looked at the card-detect yet.
I'll post bits of this to relevant lists as they are ready, not to this
list any more. If anyone would like to hear about my progress, please
let me know.
Thanks,
NeilBrown
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 833ef0590af8..45ae93114a07 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -366,6 +366,8 @@ struct mtk_mmc_compatible {
u8 clk_div_bits;
bool hs400_tune; /* only used for MT8173 */
u32 pad_tune_reg;
+ u32 caps;
+ u32 ocr_avail;
bool async_fifo;
bool data_tune;
bool busy_check;
@@ -507,6 +509,21 @@ static const struct mtk_mmc_compatible mt7622_compat = {
.support_64g = false,
};
+static const struct mtk_mmc_compatible mt7620_compat = {
+ .clk_div_bits = 8,
+ .hs400_tune = false,
+ .pad_tune_reg = MSDC_PAD_TUNE,
+ .async_fifo = false,
+ .data_tune = false,
+ .busy_check = false,
+ .stop_clk_fix = false,
+ .enhance_rx = false,
+ .caps = (MMC_CAP_4_BIT_DATA | MMC_CAP_MMC_HIGHSPEED |
+MMC_CAP_SD_HIGHSPEED),
+ .ocr_avail = (MMC_VDD_28_29 | MMC_VDD_29_30 | MMC_VDD_30_31 |
+ MMC_VDD_31_32 | MMC_VDD_32_33),
+};
+
static const struct of_device_id msdc_of_ids[] = {
{ .compatible = "mediatek,mt8135-mmc", .data = &mt8135_compat},
{ .compatible = "mediatek,mt8173-mmc", .data = &mt8173_compat},
@@ -514,6 +531,7 @@ static const struct of_device_id msdc_of_ids[] = {
{ .compatible = "mediatek,mt2701-mmc", .data = &mt2701_compat},
{ .compatible = "mediatek,mt2712-mmc", .data = &mt2712_compat},
{ .compatible = "mediatek,mt7622-mmc", .data = &mt7622_compat},
+ { .compatible = "ralink,mt7620-sdhci", .data = &mt7620_compat},
{}
};
MODULE_DEVICE_TABLE(of, msdc_of_ids);
@@ -2194,13 +2212,17 @@ static int msdc_drv_probe(struct platform_device *pdev)
if (mmc->caps & MMC_CAP_SDIO_IRQ)
mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;
- mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23;
+ mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23 |
+ host->dev_comp->caps;
+ mmc->f_max = host->src_clk_freq;
/* MMC core transfer sizes tunable parameters */
mmc->max_segs = MAX_BD_NUM;
mmc->max_seg_size = BDMA_DESC_BUFLEN;
mmc->max_blk_size = 2048;
mmc->max_req_size = 512 * 1024;
mmc->max_blk_count = mmc->max_req_size / 512;
+ mmc->ocr_avail |= host->dev_comp->ocr_avail;
+
if (host->dev_comp->support_64g)
host->dma_mask = DMA_BIT_MASK(36);
else
@@ -2226,8 +2248,13 @@ static int msdc_drv_probe(struct platform_device *pdev)
msdc_ungate_clock(host);
msdc_init_hw(host);
- ret = devm_request_irq(&pdev->dev, host->irq, msdc_irq,
-
