OK.
On 27 August 2013 09:44, Inki Dae wrote:
>
> One more thing, changed the subject to "Consider fallback option to
> allocation fail". The subject is too long :)
>
> Thanks,
> Inki Dae
>
>
>> -Original Message-
>> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
One more thing, changed the subject to "Consider fallback option to
allocation fail". The subject is too long :)
Thanks,
Inki Dae
> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
> ow...@vger.kernel.org] On Behalf Of Vikas Sajjan
> Sent: Tu
Thanks.
On 27 August 2013 08:14, Inki Dae wrote:
> Applied.
>
> Thanks,
> Inki Dae
>
>> -Original Message-
>> From: Vikas Sajjan [mailto:vikas.saj...@linaro.org]
>> Sent: Friday, August 23, 2013 3:35 PM
>> To: dri-de...@lists.freedesktop.org; inki@samsung.com
>> Cc: kgene@samsung.
Applied.
Thanks,
Inki Dae
> -Original Message-
> From: Vikas Sajjan [mailto:vikas.saj...@linaro.org]
> Sent: Friday, August 23, 2013 3:35 PM
> To: dri-de...@lists.freedesktop.org; inki@samsung.com
> Cc: kgene@samsung.com; s.nawro...@samsung.com; robdcl...@gmail.com;
> tomasz.f...@
Apologies for my previous top post reply...
Quoting Pavel Machek (2013-08-25 08:38:11)
> Is the allocation actually neccessary? At the very least this should
> test for NULL...
Thanks Pavel! I'll add the check for NULL.
name_to_dev_t expects a non-const name, but the buffer passed in
is const.
Thanks Pavel! I'll add the check for NULL.
name_to_dev_t expects a non-const name, but the buffer passed in is const.
I also am removing the '\n' if found at the end of the string which would
violate the const.
Thanks!
Sebastian
On 25 August 2013 08:38, Pavel Machek wrote:
> Hi!
>
> > Use t
adding linux-samsung-soc mailing list and Dave Airlie.
On Fri, Aug 23, 2013 at 12:05 PM, Vikas Sajjan wrote:
> To address the case where physically contiguous memory MAY NOT be a mandatory
> requirement for framebuffer for the application calling
> exynos_drm_gem_dumb_create,
> the patch adds a
On Wed, Feb 20, 2013 at 11:07 AM, Philip Colmer
wrote:
> So we could flip the management of the list on its head, then, and make the
> list wide open but blacklist spammers ... except that you then find yourself
> in a reactive mode. In other words, spam gets onto the list because the list
> is op