On 26/07/13 10:04, Laurent Pinchart wrote:
> Hi Ryan,
>
> On Friday 26 July 2013 09:45:26 Ryan Mallon wrote:
>> On 26/07/13 09:26, Laurent Pinchart wrote:
>>> Add support for passing CD/RO GPIO numbers directly to the mmc_spi
>>> driver instead of relying
On 26/07/13 09:26, Laurent Pinchart wrote:
> Add support for passing CD/RO GPIO numbers directly to the mmc_spi
> driver instead of relying solely on board code callbacks to retrieve the
> CD/RO signals values.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/mmc/host/mmc_spi.c| 32 ++
On 26/07/13 09:26, Laurent Pinchart wrote:
> Hello,
>
> This patch set replaces callbacks to board code with regulators and GPIOs in
> the mmc_spi, sh_mmcif and sh_mobile_sdhi MMC drivers.
>
> Most of the required infrastructure is in place already on the drivers side,
> except for CD/RO GPIOs su
Wolfgang Mües wrote:
> Hi,
>
> Am 29.08.2010 23:39, schrieb Ryan Mallon:
>> I see this is already applied, but why all the type trickery here? Why
>> not just:
>>
>> memcpy(dmabuf, sgbuffer, amount);
>> dmabuf += amount / sizeof(dmabuf);
>
&g
dmabuf += amount / sizeof(dmabuf);
>> }
>>
>> -kunmap_atomic(sgbuffer, KM_BIO_SRC_IRQ);
>> +kunmap_atomic(((void *)sgbuffer)-sg->offset, KM_BIO_SRC_IRQ);
void * arithmetic is a gcc-ism. Isn't it better to cast to char
7;t appear that the gpio_is_valid function can be overridden by a
platform specific version. However, as you point out, on AT91 it appears
broken since anything less than AT91_PIN_PA0 (32) is not a valid gpio.
IIRC, we can't mark static inline functions as weak, and we don't want
to turn
