Re: [PATCH 2/2] staging: wfx: apply the necessary SDIO quirks for the Silabs WF200

On Thu, 17 Feb 2022 at 10:59, Kalle Valo wrote: > > Jerome Pouiller writes: > > > From: Jérôme Pouiller > > > > Until now, the SDIO quirks are applied directly from the driver. > > However, it is better to apply the quirks before driver probing. So, > > this patch relocate the quirks in the MMC

Re: [PATCH 0/2] staging: wfx: apply SDIO suggestions

ense to carry this patch with the staging tree. I don't believe the changes to the mmc core will cause any merge conflict, so feel free to funnel this through whatever tree makes best sense. For the series: Reviewed-by: Ulf Hansson Kind regards Uffe > > > Jérôme Pouiller (2): > staging:

Re: [PATCH v9 08/24] wfx: add bus_sdio.c

On Wed, 12 Jan 2022 at 19:24, Jérôme Pouiller wrote: > > On Wednesday 12 January 2022 18:48:48 CET Pali Rohár wrote: > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you recognize the sender and know > > the content is safe.

Re: [PATCH v9 08/24] wfx: add bus_sdio.c

On Wed, 12 Jan 2022 at 12:43, Pali Rohár wrote: > > On Wednesday 12 January 2022 12:18:58 Jérôme Pouiller wrote: > > On Wednesday 12 January 2022 11:58:59 CET Pali Rohár wrote: > > > On Tuesday 11 January 2022 18:14:08 Jerome Pouiller wrote: > > > > +static const struct sdio_device_id

Re: [PATCH v9 01/24] mmc: sdio: add SDIO IDs for Silabs WF200 chip

On Tue, 11 Jan 2022 at 18:14, Jerome Pouiller wrote: > > From: Jérôme Pouiller > > Note that the values used by Silabs are uncommon. A driver cannot fully > rely on the SDIO PnP. It should also check if the device is declared in > the DT. > > So, to apply the quirks necessary for the Silabs

Re: [PATCH v9 08/24] wfx: add bus_sdio.c

[...] > +static const struct of_device_id wfx_sdio_of_match[] = { > + { .compatible = "silabs,wf200",.data = _wf200 }, > + { .compatible = "silabs,brd4001a", .data = _brd4001a }, > + { .compatible = "silabs,brd8022a", .data = _brd8022a }, > + { .compatible =

Re: [PATCH v5 08/24] wfx: add bus_sdio.c

On Fri, 1 Oct 2021 at 14:31, Kalle Valo wrote: > > Hi Ulf, > > sorry for the late reply, my Gnus tells me it took me 24 weeks to reply :) > > Ulf Hansson writes: > > > On Wed, 7 Apr 2021 at 14:00, Kalle Valo wrote: > >> > >> Ulf Hansson writes

Re: [PATCH v7 08/24] wfx: add bus_sdio.c

On Tue, 5 Oct 2021 at 10:14, Jérôme Pouiller wrote: > > On Friday 1 October 2021 17:23:16 CEST Ulf Hansson wrote: > > On Thu, 30 Sept 2021 at 19:06, Pali Rohár wrote: > > > On Thursday 30 September 2021 18:51:09 Jérôme Pouiller wrote: > > > > On Thursday 30

Re: [PATCH v7 08/24] wfx: add bus_sdio.c

On Thu, 30 Sept 2021 at 18:51, Jérôme Pouiller wrote: > > Hello Ulf, > > On Thursday 30 September 2021 12:07:55 CEST Ulf Hansson wrote: > > On Mon, 20 Sept 2021 at 18:12, Jerome Pouiller > > wrote: > > > > > > From: Jérôme Pouiller

Re: [PATCH v7 08/24] wfx: add bus_sdio.c

On Thu, 30 Sept 2021 at 19:06, Pali Rohár wrote: > > On Thursday 30 September 2021 18:51:09 Jérôme Pouiller wrote: > > Hello Ulf, > > > > On Thursday 30 September 2021 12:07:55 CEST Ulf Hansson wrote: > > > On Mon, 20 Sept 2021 at 18:12, Jerome Pouiller > >

Re: [PATCH v7 08/24] wfx: add bus_sdio.c

On Mon, 20 Sept 2021 at 18:12, Jerome Pouiller wrote: > > From: Jérôme Pouiller > > Signed-off-by: Jérôme Pouiller > --- > drivers/net/wireless/silabs/wfx/bus_sdio.c | 261 + > 1 file changed, 261 insertions(+) > create mode 100644

Re: [PATCH v5 08/24] wfx: add bus_sdio.c

On Wed, 7 Apr 2021 at 14:00, Kalle Valo wrote: > > Ulf Hansson writes: > > >> If I follow what has been done in other drivers I would write something > >> like: > >> > >> static int wfx_sdio_suspend(struct device *dev) > >> { > &

Re: [PATCH v5 08/24] wfx: add bus_sdio.c

On Tue, 23 Mar 2021 at 18:53, Jérôme Pouiller wrote: > > On Tuesday 23 March 2021 15:11:56 CET Ulf Hansson wrote: > > On Mon, 22 Mar 2021 at 18:14, Jérôme Pouiller > > wrote: > > > On Monday 22 March 2021 13:20:35 CET Ulf Hansson wrote: > > > > On Mon

Re: [PATCH v5 08/24] wfx: add bus_sdio.c

On Mon, 22 Mar 2021 at 18:14, Jérôme Pouiller wrote: > > Hello Ulf, > > On Monday 22 March 2021 13:20:35 CET Ulf Hansson wrote: > > On Mon, 15 Mar 2021 at 14:25, Jerome Pouiller > > wrote: > > > > > > From: Jérôme Pouiller > > > > > >

Re: [PATCH v5 08/24] wfx: add bus_sdio.c

On Mon, 15 Mar 2021 at 14:25, Jerome Pouiller wrote: > > From: Jérôme Pouiller > > Signed-off-by: Jérôme Pouiller > --- > drivers/net/wireless/silabs/wfx/bus_sdio.c | 259 + > 1 file changed, 259 insertions(+) > create mode 100644 drivers/net/wireless/silabs/wfx/bus_sdio.c

Re: [PATCH v2 28/48] soc/tegra: Introduce core power domain driver

On Thu, 17 Dec 2020 at 19:07, Dmitry Osipenko wrote: > > NVIDIA Tegra SoCs have multiple power domains, each domain corresponds > to an external SoC power rail. Core power domain covers vast majority of > hardware blocks within a Tegra SoC. The voltage of a power domain should > be set to a value

Re: [PATCH v2 31/48] soc/tegra: regulators: Support Core domain state syncing

-regulator voltage syncing once the state of domain is synced, at > this point the Core voltage is allowed to go lower. > > Signed-off-by: Dmitry Osipenko This looks reasonable to me, feel free to add: Reviewed-by: Ulf Hansson Kind regards Uffe > --- > drivers/so

Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs

On Thu, 12 Nov 2020 at 23:14, Dmitry Osipenko wrote: > > 12.11.2020 23:43, Thierry Reding пишет: > >> The difference in comparison to using voltage regulator directly is > >> minimal, basically the core-supply phandle is replaced is replaced with > >> a power-domain phandle in a device tree. > >

Re: [PATCH v1 01/30] dt-bindings: host1x: Document OPP and voltage regulator properties

On Thu, 5 Nov 2020 at 00:44, Dmitry Osipenko wrote: > > Document new DVFS OPP table and voltage regulator properties of the > Host1x bus and devices sitting on the bus. > > Signed-off-by: Dmitry Osipenko > --- > .../display/tegra/nvidia,tegra20-host1x.txt | 56 +++ > 1 file

Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs

On Sun, 8 Nov 2020 at 13:19, Dmitry Osipenko wrote: > > 05.11.2020 18:22, Dmitry Osipenko пишет: > > 05.11.2020 12:45, Ulf Hansson пишет: > > ... > >> I need some more time to review this, but just a quick check found a > >> few potential issues... > >

Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs

On Thu, 5 Nov 2020 at 12:13, Viresh Kumar wrote: > > On 05-11-20, 11:56, Ulf Hansson wrote: > > On Thu, 5 Nov 2020 at 11:40, Viresh Kumar wrote: > > > Btw, how do we identify if it is a power domain or a regulator ? > > To be honest, I was a bit afraid and embar

Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs

On Thu, 5 Nov 2020 at 11:40, Viresh Kumar wrote: > > On 05-11-20, 11:34, Ulf Hansson wrote: > > I am not objecting about scaling the voltage through a regulator, > > that's fine to me. However, encoding a power domain as a regulator > > (even if it may seem like a regula

Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs

On Thu, 5 Nov 2020 at 11:06, Viresh Kumar wrote: > > On 05-11-20, 10:45, Ulf Hansson wrote: > > + Viresh > > Thanks Ulf. I found a bug in OPP core because you cc'd me here :) Happy to help. :-) > > > On Thu, 5 Nov 2020 at 00:44, Dmitry Osipenko wrote: > >

Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs

+ Viresh On Thu, 5 Nov 2020 at 00:44, Dmitry Osipenko wrote: > > Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces > power consumption and heating of the Tegra chips. Tegra SoC has multiple > hardware units which belong to a core power domain of the SoC and share > the

Re: [PATCH v2 01/24] mmc: sdio: add SDIO IDs for Silabs WF200 chip

; the DT. > > Signed-off-by: Jérôme Pouiller Acked-by: Ulf Hansson Kind regards Uffe > --- > include/linux/mmc/sdio_ids.h | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h > index 12036619346c..20a48162

Re: [PATCH 07/23] wfx: add bus_sdio.c

On Thu, 15 Oct 2020 at 16:03, Jérôme Pouiller wrote: > > On Wednesday 14 October 2020 14:43:34 CEST Pali Rohár wrote: > > On Wednesday 14 October 2020 13:52:15 Jérôme Pouiller wrote: > > > On Tuesday 13 October 2020 22:11:56 CEST Pali Rohár wrote: > > > > On Monday 12 October 2020 12:46:32 Jerome

Re: [PATCH 07/23] wfx: add bus_sdio.c

On Mon, 12 Oct 2020 at 12:47, Jerome Pouiller wrote: > > From: Jérôme Pouiller Please fill out this commit message to explain a bit more about the patch and the HW it enables support for. > > Signed-off-by: Jérôme Pouiller > --- > drivers/net/wireless/silabs/wfx/bus_sdio.c | 269

Re: [PATCH v7 00/17] wilc1000: move out of staging

On Wed, 1 Jul 2020 at 09:55, Pali Rohár wrote: > > On Tuesday 30 June 2020 03:17:01 ajay.kat...@microchip.com wrote: > > On 29/06/20 6:56 pm, Pali Rohár wrote: > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know > > > the content is safe > > > > > > On Tuesday 23 June

Re: [RFC RFT PATCH 0/4] gpiolib: speed up GPIO array processing

phy-mapphone-mdm6600.c | 21 +- > drivers/staging/iio/adc/ad7606.c| 12 - > drivers/tty/serial/serial_mctrl_gpio.c |9 > include/linux/gpio/consumer.h | 35 ++- > 16 files changed, 410 insertions(+), 182 deletions(-) > For the mmc related ch

Re: [PATCH v3 13/20] mmc: Remove depends on HAS_DMA in case of platform dependency

testing. > > Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> > Reviewed-by: Mark Brown <broo...@kernel.org> > Acked-by: Robin Murphy <robin.mur...@arm.com> > Acked-by: Ulf Hansson <ulf.hans...@linaro.org> Thanks, applied for next! Kind regrds Uffe

Re: [PATCH 00/15] ARM: pxa: switch to DMA slave maps

On 4 April 2018 at 21:56, Boris Brezillon <boris.brezil...@bootlin.com> wrote: > On Wed, 04 Apr 2018 21:49:26 +0200 > Robert Jarzmik <robert.jarz...@free.fr> wrote: > >> Ulf Hansson <ulf.hans...@linaro.org> writes: >> >> > On 2 April 2018 at 16:2

Re: [PATCH 00/15] ARM: pxa: switch to DMA slave maps

his tree > either > an Ack or "I want to take through my tree" will be spared in the next > iterations > of this serie. Perhaps an option is to send this hole series as PR for 3.17 rc1, that would removed some churns and make this faster/easier? Well, if you receive the needed ack

Re: [PATCH v2 13/21] mmc: Remove depends on HAS_DMA in case of platform dependency

testing. > > Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> > Reviewed-by: Mark Brown <broo...@kernel.org> > Acked-by: Robin Murphy <robin.mur...@arm.com> Acked-by: Ulf Hansson <ulf.hans...@linaro.org> > --- > v2: > - Add Reviewed-by, Acked-

Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

[...] >> > I'd like to know if any progress has been made on that problem (I may >> > have missed patches). >> > Had you had the time to look at the issue? >> >> I have looked at the issue, but not manage to cook some patches for it. >> >> However, it's on my top of my TODO list for mmc. No

Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

On 8 February 2018 at 15:59, Quentin Schulz <quentin.sch...@bootlin.com> wrote: > Hi Ulf, > > On Wed, Aug 30, 2017 at 03:43:49PM +0200, Ulf Hansson wrote: >> On 30 August 2017 at 14:44, Hans de Goede <hdego...@redhat.com> wrote: >> > Hi, >> > >

Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

On 30 August 2017 at 14:44, Hans de Goede wrote: > Hi, > > > On 21-07-17 16:35, Quentin Schulz wrote: >> >> From: Hans de Goede >> >> Some sdio devices have a multiple stage bring-up process. Specifically >> the esp8089 (for which an out of tree driver

Re: [PATCH v2 5/7] staging: board: Add support for devices with complex dependencies

On 4 September 2015 at 17:03, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Ulf, > > On Fri, 4 Sep 2015, Ulf Hansson wrote: >> On 3 September 2015 at 15:35, Geert Uytterhoeven <ge...@linux-m68k.org> >> wrote: >> > On Thu, Sep 3, 2015 at 2:

Re: [PATCH v2 5/7] staging: board: Add support for devices with complex dependencies

On 3 September 2015 at 15:35, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Ulf, > > On Thu, Sep 3, 2015 at 2:53 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 17 June 2015 at 10:38, Geert Uytterhoeven <geert+rene...@glider.be> wrote: >>> A

Re: [PATCH v2 5/7] staging: board: Add support for devices with complex dependencies

On 17 June 2015 at 10:38, Geert Uytterhoeven wrote: > Add support for easy registering of one ore more platform devices that > may: > - need clocks that are described in DT, > - be part of a PM Domain. > > All these dependencies are optional. > > Signed-off-by: Geert

Re: [PATCH] sdhci: rtsx: fix 64 BIT DMA quirks

On 7 April 2015 at 05:32, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn rts5250 chip failed handle 64 bit ADMA for address below 4G. Add 64 BIT quirks to disable this feature. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn Thanks! Applied, with a

Re: [PATCH 0/2] mmc: rtsx: add check before sending request

On 14 January 2015 at 04:09, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn Add check before sending request can make request return faster. - finish request if no card exist This can make request finish faster, especial for some sdio card, when card

Re: [PATCH v5 1/6] mfd: rtsx: add func to split u32 into register

On 20 January 2015 at 15:47, Lee Jones lee.jo...@linaro.org wrote: On Tue, 23 Dec 2014, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn Add helper function to write u32 to registers, if we want to put u32 value to 4 continuous register, this can help us reduce

Re: [PATCH v4 1/6] mfd: rtsx: add func to split u32 into register

On 8 December 2014 at 10:57, Lee Jones lee.jo...@linaro.org wrote: On Fri, 05 Dec 2014, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn Add helper function to write u32 to registers, if we want to put u32 value to 4 continuous register, this can help us reduce

Re: [PATCH v2 0/2] mmc: rtsx: add support for sdio card

On 2 December 2014 at 02:36, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn v3: rtsx_pci_sdmmc.c: - dump_reg_range - remove unused pointer check - fix start index I can't find v3. Kind regards Uffe v2: rtsx_pci.h: - remove

Re: [PATCH 1/2] mmc: core: Add new power_mode MMC_POWER_UNDEFINED

On 24 September 2014 11:07, Roger Tseng rogera...@realtek.com wrote: Define new macro MMC_POWER_UNDEFINED for power_mode in struct mmc_ios. It will also be set as the initial value of host-ios.power_mode in mmc_start_host(). For hosts with MMC_CAP2_NO_PRESCAN_POWERUP, this makes the later

Re: [PATCH 2/2] mmc: rtsx_pci: Set power related cap2 macros

On 24 September 2014 11:07, Roger Tseng rogera...@realtek.com wrote: Set MMC_CAP2_NO_PRESCAN_POWERUP and MMC_CAP2_FULL_PWR_CYCLE for rtsx_pci_sdmmc and rtsx_usb_sdmmc to reflect properties of Realtek card reader hosts. Signed-off-by: Roger Tseng rogera...@realtek.com Thanks! Applied for

Re: [PATCH] mmc: rtsx: add card power off during probe

[...] In that case, don't forget to enable MMC_CAP2_FULL_PWR_CYCLE. if MMC_CAP2_NO_PRESCAN_POWERUP enable, will call mmc_power_off() at start, then it will check ios.power_mode, but the state is MMC_POWER_OFF and just return. Uhh, that's right! So, I wonder why we invokes

Re: [PATCH] mmc: rtsx: add card power off during probe

On 12 September 2014 03:39, micky_ch...@realsil.com.cn wrote: From: Roger Tseng rogera...@realtek.com Some platform have both UEFI driver and MFD/mmc driver, if entering linux while card in the slot, the card power is already on, and rtsx-mmc driver have no chance to make card power off.

Re: [PATCH 1/2] mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response

On 15 August 2014 08:06, rogera...@realtek.com wrote: From: Roger Tseng rogera...@realtek.com Current code erroneously fill the last byte of R2 response with an undefined value. In addition, the controller actually 'offloads' the last byte (CRC7, end bit) while receiving R2 response and thus

Re: [PATCH 2/2] mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response

On 15 August 2014 08:06, rogera...@realtek.com wrote: From: Roger Tseng rogera...@realtek.com Current code erroneously fill the last byte of R2 response with an undefined value. In addition, the controller actually 'offloads' the last byte (CRC7, end bit) while receiving R2 response and thus

Re: [PATCH] mmc: rtsx: fix incorrect last byte in R2 response

On 14 August 2014 08:06, Roger Tseng rogera...@realtek.com wrote: On Wed, 2014-08-13 at 17:09 +0200, Ulf Hansson wrote: On 11 August 2014 10:32, rogera...@realtek.com wrote: From: Roger Tseng rogera...@realtek.com Current code erroneously fill the last byte of R2 response

Re: [PATCH] mmc: rtsx: fix incorrect last byte in R2 response

On 11 August 2014 10:32, rogera...@realtek.com wrote: From: Roger Tseng rogera...@realtek.com Current code erroneously fill the last byte of R2 response with an undefined value. In addition, it is impossible to obtain the real values since the controller actually 'offloads' the last

Re: [PATCH 2/2] mmc: rtsx: add support for async request

micky_ch...@realsil.com.cn Acked-by: Ulf Hansson ulf.hans...@linaro.org I assume Lee will pick this patchset through his mfd tree then. If not, ping me and I will help. Kind regards Uffe --- drivers/mmc/host/rtsx_pci_sdmmc.c | 133 +++-- 1 file changed

Re: [PATCH 2/2] mmc: rtsx: add support for async request

On 18 June 2014 03:17, micky micky_ch...@realsil.com.cn wrote: On 06/17/2014 03:45 PM, Ulf Hansson wrote: On 17 June 2014 03:04, micky micky_ch...@realsil.com.cn wrote: On 06/16/2014 08:40 PM, Ulf Hansson wrote: On 16 June 2014 11:09, micky micky_ch...@realsil.com.cn wrote: On 06/16/2014

Re: [PATCH 2/2] mmc: rtsx: add support for async request

On 18 June 2014 12:08, micky micky_ch...@realsil.com.cn wrote: On 06/18/2014 03:39 PM, Ulf Hansson wrote: On 18 June 2014 03:17, micky micky_ch...@realsil.com.cn wrote: On 06/17/2014 03:45 PM, Ulf Hansson wrote: On 17 June 2014 03:04, micky micky_ch...@realsil.com.cn wrote: On 06/16/2014

Re: [PATCH 2/2] mmc: rtsx: add support for async request

On 17 June 2014 03:04, micky micky_ch...@realsil.com.cn wrote: On 06/16/2014 08:40 PM, Ulf Hansson wrote: On 16 June 2014 11:09, micky micky_ch...@realsil.com.cn wrote: On 06/16/2014 04:42 PM, Ulf Hansson wrote: @@ -36,7 +37,10 @@ struct realtek_pci_sdmmc { struct rtsx_pcr

Re: [PATCH 2/2] mmc: rtsx: add support for async request

On 6 June 2014 09:05, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn Add support for non-blocking request, pre_req() runs dma_map_sg() and post_req() runs dma_unmap_sg(). This patch can increase card read/write speed, especially for high speed card and slow

Re: [PATCH 2/2] mmc: rtsx: add support for async request

On 16 June 2014 11:09, micky micky_ch...@realsil.com.cn wrote: On 06/16/2014 04:42 PM, Ulf Hansson wrote: @@ -36,7 +37,10 @@ struct realtek_pci_sdmmc { struct rtsx_pcr *pcr; struct mmc_host *mmc; struct mmc_request *mrq; + struct

Re: [PATCH 1/2] mfd: rtsx: add dma transfer function

On 16 June 2014 14:20, Lee Jones lee.jo...@linaro.org wrote: From: Micky Ching micky_ch...@realsil.com.cn rtsx driver using a single function for transfer data, dma map/unmap are placed in one fix function. We need map/unmap dma in different place(for mmc async driver), so add three function

Re: [PATCH 1/2] mmc: rtsx: Revert mmc: rtsx: modify error handleandremove smatch warnings

Chris' drops this patch - causing Stephen to not merge the mmc tree for a while. I suppose that's the best we can do, until Chris shows up again. Kind regards Ulf Hansson From: Micky Chingmicky_ch...@realsil.com.cn This reverts commit 1f7b581b3ffcb2a8437397a02f4af89fa6934d08. The patch depend

Re: [PATCH] mmc: rtsx: usb backend needs LED support

': rtsx_usb_sdmmc.c:(.text+0x2a197e): undefined reference to `led_classdev_register' Fix by excluding such condition when defining macro RTSX_USB_USE_LEDS_CLASS. Signed-off-by: Roger Tseng rogera...@realtek.com Acked-by: Ulf Hansson ulf.hans...@linaro.org Would this patch be merged into linux-next

Re: [PATCH v2] mmc: rtsx: fix possible linking error if built-in

such condition when defining macro RTSX_USB_USE_LEDS_CLASS. Signed-off-by: Roger Tseng rogera...@realtek.com Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Ulf Hansson ulf.hans...@linaro.org --- v2 by Arnd: change the second #ifdef as well. Thanks Arnd, Roger - I will include this one in PR

Re: [PATCH 2/2] mmc: rtsx: Revert mmc: rtsx: add support for pre_req and post_req

On 29 April 2014 09:36, Ulf Hansson ulf.hans...@linaro.org wrote: On 29 April 2014 03:54, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d. commit mmc: rtsx: add support for pre_req and post_req did

Re: [PATCH 1/2] mmc: rtsx: Revert mmc: rtsx: modify error handle and remove smatch warnings

, but the previous patch was discard. So we have to delete the patch. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn Acked-by: Ulf Hansson ulf.hans...@linaro.org The patch this is reverting has been recently queued for 3.16. So we may either apply the revert or just drop the patch from the mmc-next

Re: [PATCH 2/2] mmc: rtsx: Revert mmc: rtsx: add support for pre_req and post_req

avoid using the spinlock and also avoid the problem. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn Acked-by: Ulf Hansson ulf.hans...@linaro.org --- drivers/mfd/rtsx_pcr.c| 132 drivers/mmc/host/rtsx_pci_sdmmc.c | 418

Re: [PATCH] mmc: rtsx: usb backend needs LED support

instead. There are already some ifdefs hackery for making it optional to use leds, apparently that's not working properly. Kind regards Ulf Hansson Signed-off-by: Arnd Bergmann a...@arndb.de diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 92d91fe..66aedf3 100644

Re: [PATCH] mmc: rtsx: Revert mmc: rtsx: add support for pre_req and post_req

avoid using the spinlock and also avoid the problem. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn Acked-by: Ulf Hansson ulf.hans...@linaro.org Chris, could you pick up this for fixes instead of queuing it for 3.16? Kind regards Uffe --- drivers/mfd/rtsx_pcr.c| 132

Re: [PATCH] mmc: rtsx: Revert mmc: rtsx: add support for pre_req and post_req

On 28 April 2014 14:29, Lee Jones lee.jo...@linaro.org wrote: From: Micky Ching micky_ch...@realsil.com.cn This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d. Why was this patch even merged without an MFD Ack? commit mmc: rtsx: add support for pre_req and post_req did use

Re: [PATCH v7 0/4] Add modules for realtek USB card reader

driver. The rest I am fine with if Lee can take though the mfd tree. Kind regards Ulf Hansson Best regards, Roger Tseng ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v6 3/4] mmc: Add realtek USB sdmmc host driver

On 9 April 2014 08:16, rogera...@realtek.com wrote: From: Roger Tseng rogera...@realtek.com Realtek USB SD/MMC host driver provides mmc host support based on the Realtek USB card reader MFD driver. Signed-off-by: Roger Tseng rogera...@realtek.com --- drivers/mmc/host/Kconfig |

Re: [PATCH v4 2/3] mmc: Add realtek USB sdmmc host driver

On 12 February 2014 11:00, rogera...@realtek.com wrote: From: Roger Tseng rogera...@realtek.com Realtek USB SD/MMC host driver provides mmc host support based on the Realtek USB card reader MFD driver. Signed-off-by: Roger Tseng rogera...@realtek.com Reviewed-by: Ulf Hansson ulf.hans

Re: [PATCH v3 2/3] mmc: Add realtek USB sdmmc host driver

On 11 February 2014 10:27, Roger rogera...@realtek.com wrote: On 02/10/2014 10:58 PM, Ulf Hansson wrote: On 6 February 2014 15:35, rogera...@realtek.com wrote: From: Roger Tseng rogera...@realtek.com Realtek USB SD/MMC host driver provides mmc host support based on the Realtek USB card

Re: [PATCH v3 1/3] mfd: Add realtek USB card reader driver

will resend v4 later but currently I don't plan to change the 1/3 part(for mfd) in it. Would you wait for and re-apply the v4 submission or give any advice? Just send a v4 of PATCH 2/3 and 3/3, that should be fine I think. Kind regards Ulf Hansson ___ devel