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
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
> > >
> > >
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
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)
> >> {
> &
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 drivers/net/wireless/silabs/wfx/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
> >
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
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
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:
&
[...]
> +static const struct of_device_id wfx_sdio_of_match[] = {
> + { .compatible = "silabs,wf200",.data = &pdata_wf200 },
> + { .compatible = "silabs,brd4001a", .data = &pdata_brd4001a },
> + { .compatible = "silabs,brd8022a", .data = &pdata_brd8022a },
> + { .compat
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 WF200
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 wfx_sdio_ids
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.
>
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 +
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
he 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
+ 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 core
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:
> >
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 r
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 embarrassed
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...
> >
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 cha
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.
> > T
-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
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
On 2 December 2014 at 02:36, wrote:
> From: Micky Ching
>
> 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 unused rtsx_pci_write_le32
> - add SD_CMD_ST
On 2 December 2014 at 02:36, wrote:
> From: Micky Ching
>
> Add support for sdio card by SD interface. The main change is data
> transfer mode, When read data, host wait data transfer while command
> start. When write data, host will start data transfer after command get
> response. The transfer
On 8 December 2014 at 10:57, Lee Jones wrote:
> On Fri, 05 Dec 2014, micky_ch...@realsil.com.cn wrote:
>> From: Micky Ching
>>
>> Add helper function to write u32 to registers, if we want to put u32
>> value to 4 continuous register, this can help us reduce tedious work.
>>
>> Signed-off-by: Mick
On 5 December 2014 at 06:54, wrote:
> From: Micky Ching
>
> v4:
> split patch in more detailed patches. no code changes diff v3.
>
> v3:
> rtsx_pci_sdmmc.c:
> - dump_reg_range
> - remove unused pointer check
> - fix start index
> v2:
> rtsx_pci.h:
> - remove unused rtsx
On 23 December 2014 at 02:19, wrote:
> From: Micky Ching
>
> v5:
> fix patch(5) building error, no code change diff v4.
>
> v4:
> split patch in more detailed patches. no code changes diff v3.
>
> v3:
> rtsx_pci_sdmmc.c:
> - dump_reg_range
> - remove unused pointer check
>
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
k 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 acks of course.
For the mmc c
On 4 April 2018 at 21:56, Boris Brezillon wrote:
> On Wed, 04 Apr 2018 21:49:26 +0200
> Robert Jarzmik wrote:
>
>> Ulf Hansson writes:
>>
>> > On 2 April 2018 at 16:26, Robert Jarzmik wrote:
>> >> Hi,
>> >>
>> >> T
ff-by: Geert Uytterhoeven
> Reviewed-by: Mark Brown
> Acked-by: Robin Murphy
> Acked-by: Ulf Hansson
Thanks, applied for next!
Kind regrds
Uffe
> ---
> v3:
> - Add Acked-by,
> - Rebase to v4.17-rc1,
>
> v2:
> - Add Reviewed-by, Acked-by,
> - Dr
On 7 April 2015 at 05:32, wrote:
> From: Micky Ching
>
> rts5250 chip failed handle 64 bit ADMA for address below 4G.
> Add 64 BIT quirks to disable this feature.
>
> Signed-off-by: Micky Ching
Thanks! Applied, with a minor updated commit message header.
Kind regards
Uffe
> ---
> drivers/mm
On 11 February 2014 10:27, Roger wrote:
> On 02/10/2014 10:58 PM, Ulf Hansson wrote:
>>
>> On 6 February 2014 15:35, wrote:
>>>
>>> From: Roger Tseng
>>>
>>> Realtek USB SD/MMC host driver provides mmc host support based on the
>>> R
de 100644 include/linux/mfd/rtsx_usb.h
>>
>>
>> Applied with Greg's Ack.
>>
> Thanks. But I have to modify some places in PATCH 2/3 and 3/3 according to
> Ulf's suggestion. I will resend v4 later but currently I don&
On 12 February 2014 11:00, wrote:
> From: Roger Tseng
>
> Realtek USB SD/MMC host driver provides mmc host support based on the Realtek
> USB card reader MFD driver.
>
> Signed-off-by: Roger Tseng
Reviewed-by: Ulf Hansson
> ---
> drivers/mmc/host/Kconfig
ch of your patches. Patch2 has a warning you should fix.
Kind regards
Ulf Hansson
>
> Micky Ching (2):
> mmc: rtsx: add R1-no-CRC mmc command type handle
> mmc: rtsx: modify error handle and remove smatch warnings
>
> drivers/mmc/host/rtsx_pci_sdmmc.c | 121
> ++
On 26 March 2014 02:29, micky wrote:
> Hi Ulf,
>
> On 03/25/2014 06:44 PM, Ulf Hansson wrote:
>>
>> On 25 March 2014 10:47, wrote:
>>>
>>> From: Micky Ching
>>>
>>> Add new command type(R1 without CRC) handle, without this
>>&
type handle
> mmc: rtsx: modify error handle and remove smatch warnings
>
> drivers/mmc/host/rtsx_pci_sdmmc.c | 122
> +
> 1 file changed, 68 insertions(+), 54 deletions(-)
Acked-by: Ulf Hansson
>
> --
> 1.
On 9 April 2014 08:16, wrote:
> From: Roger Tseng
>
> Realtek USB SD/MMC host driver provides mmc host support based on the Realtek
> USB card reader MFD driver.
>
> Signed-off-by: Roger Tseng
> ---
> drivers/mmc/host/Kconfig |7 +
> drivers/mmc/host/Makefile |1 +
> d
help to remove the staging one.
>>>>
>>>>
>>>> Looks good to me.
>>>
>>>
>>> Is that an Ack?
>>
>> Acked-by: Oliver
>>
>> Sorry
>> Oliver
>>
> Lee,
>
> W
also avoid the problem.
>
> Signed-off-by: Micky Ching
Acked-by: Ulf Hansson
Chris, could you pick up this for "fixes" instead of queuing it for 3.16?
Kind regards
Uffe
> ---
> drivers/mfd/rtsx_pcr.c| 132
> drivers/mmc/host/rtsx_pci_sdmmc.c |
dmmc.c | 418
>> ++---
>> include/linux/mfd/rtsx_common.h |1 -
>> include/linux/mfd/rtsx_pci.h |6 -
>> 4 files changed, 109 insertions(+), 448 deletions(-)
>
> This patch should be sent to the -rcs as soon as possible:
D
On 28 April 2014 14:29, Lee Jones wrote:
>> >> From: Micky Ching
>> >>
>> >> This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
>> >
>> > Why was this patch even merged without an MFD Ack?
>> >
>> >> commit did use
>> >> mutex_unlock() in tasklet, but mutex_unlock() can't used in
>> >
On 20 January 2015 at 15:47, Lee Jones wrote:
> On Tue, 23 Dec 2014, micky_ch...@realsil.com.cn wrote:
>
>> From: Micky Ching
>>
>> Add helper function to write u32 to registers, if we want to put u32
>> value to 4 continuous register, this can help us reduce tedious work.
>>
>> Signed-off-by: Mi
On 14 January 2015 at 04:09, wrote:
> From: Micky Ching
>
> 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 removed, there still a lot of command pending,
>
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 is available) loads firmware
>> on the first
Signed-off-by: Micky Ching
Acked-by: Ulf Hansson
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
branch.
Kind regards
Ulf Hansson
> ---
> drivers/mmc/host/rtsx_pci_sdmmc.c | 119
> +++
also avoid the problem.
>
> Signed-off-by: Micky Ching
Acked-by: Ulf Hansson
> ---
> drivers/mfd/rtsx_pcr.c| 132
> drivers/mmc/host/rtsx_pci_sdmmc.c | 418
> ++---
> include/linux/mfd/rtsx_common.h |1 -
>
ig
I think the proper solution is to fix the dependency in the driver code 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
>
> diff --git a/dri
On 30 April 2014 05:34, Roger wrote:
>
> On 04/29/2014 08:46 PM, Arnd Bergmann wrote:
>>
>> On Tuesday 29 April 2014 13:05:15 Ulf Hansson wrote:
>>>
>>> On 29 April 2014 11:45, Arnd Bergmann wrote:
>>>>
>>>> drivers/built-in.o: In
On 29 April 2014 09:36, Ulf Hansson wrote:
> On 29 April 2014 03:54, wrote:
>> From: Micky Ching
>>
>> This reverts commit c42deffd5b53c9e583d83c7964854ede2f12410d.
>>
>> commit did use
>> mutex_unlock() in tasklet, but mutex_unlock() can't used in
thwell's linux-next
tree, until 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 Ching
>> >>>
>> >&g
gt;> rtsx_usb_sdmmc.c:(.text+0x2a018e): undefined reference to
>>> `led_classdev_unregister'
>>> drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe':
>>> rtsx_usb_sdmmc.c:(.text+0x2a197e): undefined reference to
>>> `led_classdev_register'
>>
led_classdev_register'
>
> Fix by excluding such condition when defining macro RTSX_USB_USE_LEDS_CLASS.
>
> Signed-off-by: Roger Tseng
> Signed-off-by: Arnd Bergmann
> Acked-by: Ulf Hansson
> ---
> v2 by Arnd: change the second #ifdef as well.
Thanks Arnd, Roger - I
On 6 June 2014 09:05, wrote:
> From: Micky Ching
>
> 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 speed CPU.
>
> Test on intel i3(800MHz - 2.3GHz) p
On 16 June 2014 11:09, micky 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;
>>> >
On 16 June 2014 14:20, Lee Jones wrote:
>> From: Micky Ching
>>
>> 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 for dma map, dma transfer and
>> dma
On 17 June 2014 03:04, micky wrote:
> On 06/16/2014 08:40 PM, Ulf Hansson wrote:
>>
>> On 16 June 2014 11:09, micky wrote:
>>>
>>> On 06/16/2014 04:42 PM, Ulf Hansson wrote:
>>>>>
>>>>> @@ -36,7 +37,10 @@ struct realtek_
On 18 June 2014 03:17, micky wrote:
> On 06/17/2014 03:45 PM, Ulf Hansson wrote:
>>
>> On 17 June 2014 03:04, micky wrote:
>>>
>>> On 06/16/2014 08:40 PM, Ulf Hansson wrote:
>>>>
>>>> On 16 June 2014 11:09, micky wro
On 18 June 2014 12:08, micky wrote:
> On 06/18/2014 03:39 PM, Ulf Hansson wrote:
>>
>> On 18 June 2014 03:17, micky wrote:
>>>
>>> On 06/17/2014 03:45 PM, Ulf Hansson wrote:
>>>>
>>>> On 17 June 2014 03:04, micky wrote:
>>>>&
el i3(800MHz - 2.3GHz) performance mode(2.3GHz), SD card
> clock 208MHz
>
> run dd if=/dev/mmcblk0 of=/dev/null bs=64k count=1024
> before:
> 67108864 bytes (67 MB) copied, 0.85427 s, 78.6 MB/s
> after:
> 67108864 bytes (67 MB) copied, 0.74799 s, 89.7 MB/s
>
> Signed-off-by
On 12 September 2014 03:39, wrote:
> From: Roger Tseng
>
> 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. This will lead UHSI card
> failed to enter UHS
On 17 September 2014 11:11, micky wrote:
> On 09/17/2014 02:01 AM, Ulf Hansson wrote:
>>
>> On 12 September 2014 03:39, wrote:
>>>
>>> From: Roger Tseng
>>>
>>> Some platform have both UEFI driver and MFD/mmc driver, if entering
>>>
[...]
>>
>> 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 w
On 22 September 2014 12:09, Roger Tseng wrote:
> On Thu, 2014-09-18 at 23:14 +0200, Ulf Hansson wrote:
>> [...]
>>
>> >>
>> >> In that case, don't forget to enable MMC_CAP2_FULL_PWR_CYCLE.
>> >>
>> >> >
>> >> &
On 24 September 2014 11:07, Roger Tseng 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
> mmc_power_off() d
On 24 September 2014 11:07, Roger Tseng 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
Thanks! Applied for next!
Kind regards
Uffe
> ---
> drivers
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 Uytterhoeven
> ---
> v2:
On 3 September 2015 at 15:35, Geert Uytterhoeven wrote:
> Hi Ulf,
>
> On Thu, Sep 3, 2015 at 2:53 PM, Ulf Hansson wrote:
>> On 17 June 2015 at 10:38, Geert Uytterhoeven wrote:
>>> Add support for easy registering of one ore more platform devices that
>>>
On 4 September 2015 at 17:03, Geert Uytterhoeven wrote:
> Hi Ulf,
>
> On Fri, 4 Sep 2015, Ulf Hansson wrote:
>> On 3 September 2015 at 15:35, Geert Uytterhoeven
>> wrote:
>> > On Thu, Sep 3, 2015 at 2:53 PM, Ulf Hansson wrote:
>> >> On
On 11 August 2014 10:32, wrote:
> From: Roger Tseng
>
> 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 byte(CRC7, end bit) while receiving R2
> respo
On 14 August 2014 08:06, Roger Tseng wrote:
> On Wed, 2014-08-13 at 17:09 +0200, Ulf Hansson wrote:
>> On 11 August 2014 10:32, wrote:
>> > From: Roger Tseng
>> >
>> > Current code erroneously fill the last byte of R2 response with an
>> > undefi
On 15 August 2014 08:06, wrote:
> From: Roger Tseng
>
> 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 it's impossible to get
> the
> actua
On 15 August 2014 08:06, wrote:
> From: Roger Tseng
>
> 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 it's impossible to get
> the
> actua
On 8 February 2018 at 15:59, Quentin Schulz 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 wrote:
>> > Hi,
>> >
>> >
>> > On 21-07-17 16:35, Quentin Schulz wrote
[...]
>> > 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 promis
ff-by: Geert Uytterhoeven
> Reviewed-by: Mark Brown
> Acked-by: Robin Murphy
Acked-by: Ulf Hansson
> ---
> v2:
> - Add Reviewed-by, Acked-by,
> - Drop RFC state,
> - Split per subsystem.
> ---
> drivers/mmc/host/Kconfig | 10 ++
> 1 file changed,
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 202
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):
>
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
83 matches
Mail list logo
