linux-kernel - Re: [PATCH v2 0/6] ARM: dts: Use correct CD properties for SDIO and eMMC in Snow and Peach

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 17 Oct 2015 08:46:28 +0900
From:	Kukjin Kim <kgene@...nel.org>
To:	Javier Martinez Canillas <javier@....samsung.com>
CC:	Alim Akhtar <alim.akhtar@...sung.com>,
	linux-kernel@...r.kernel.org,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Kukjin Kim <kgene@...nel.org>,
	Douglas Anderson <dianders@...omium.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	linux-arm-kernel@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org
Subject: Re: [PATCH v2 0/6] ARM: dts: Use correct CD properties for SDIO and
 eMMC in Snow and Peach

On 10/16/15 22:48, Javier Martinez Canillas wrote:
> Hello Alim,
> 
> On 10/16/2015 01:37 PM, Alim Akhtar wrote:
>> Hi Javier,
>>
>> On 10/15/2015 10:21 PM, Javier Martinez Canillas wrote:
>>> Hello,
>>>
>>> The Exynos Chromebooks DTS don't use the correct card detection properties
>>> since these were carried from the vendor tree that had a reason to do so.
>>>
>>> There are two things that I noticed:
>>>
>>> 1) The Marvell WiFi SDIO is marked as broken-cd instead of non-removable:
>>>
>>> This causes the device to be removed when the system enters into a suspend
>>> state which leads to the following warning when the system is resumed:
>>>
>>> [  181.944636] mmc2: error -2 during resume (card was removed?)
>>>
>>> The rationale for using broken-cd is explained in downstream commit [0] and
>>> was that using the non-removable property caused issues with the mwifiex
>>> driver since the reset logic called the mmc_{remove,add}_host() functions.
>>>
>>> But the reset logic in the mwifiex mainline driver has changed and this is
>>> no longer the case so it's safe to use the non-removable property AFAICT.
>>>
>> Good to know it is fixed now. This is fixed in firmware or in the driver?
>>
> 
> The fix is only in the driver. In fact, I'm using the same firmware from
> the ChromeOS rootfs for both the v3.8 vendor tree and mainline.
> 
> So IIUC, the problem with the vendor tree was that the mwifiex SDIO driver
> mwifiex_sdio_reset_work() function did a card reset by calling the functions
> mmc_remove_host() and then mmc_add_host().
> 
> But this didn't play nice with MMC_CAP_NONREMOVABLE since mmc_rescan() just
> returns if the flag is set so the card wouldn't be tried to be detected again.
> 
> After commit ("b4336a282db8 mwifiex: sdio: reset adapter using mmc_hw_reset"),
> the card is reset by doing a power cycle so that's why "non-removable" can be
> used now instead of "broken-cd".
> 
>>> 2) The eMMC node has both broken-cd and non-removable but the MMC DT binding
>>> doc (Documentation/devicetree/bindings/mmc/mmc.txt) mentions that only one
>>> of these card detection properties should be used.
>>>
>> This change looks ok, will take a closer look once I am back to my work station.
>>
Actually, looks good to me +1.
Let me take this series once get the feedback from Alim.

Thanks,
Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/