Contact: claims.your @cheapnet.it
Regards,
Mark Suzman
CEO, Board Member, Bill & Melinda Gates Foundation
©1991-2022 Bill & Melinda Gates Foundation. All rights
Hello,
Good day,
The HSBC Bank is a financial institution in United Kingdom. We
promotes long-term,sustainable and broad-based economic growth in
developing and emerging countries by providing financial support like
loans and investment to large, small and
medium-sized companies (SMEs) as well as
Hello,
The HSBC Bank is a financial institution in United Kingdom. We
promotes long-term,sustainable and broad-based economic growth in
developing and emerging countries by providing financial support like
loans and investment to large, small and
medium-sized companies (SMEs) as well as fast-growi
ported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
My Dear Friend
This letter is to acknowledge the substantial contributions of time and
energy you have made in trying to assist to claim the fund through
your account, despite that it failed us because of your inability to
continue financing the transaction.
Besides I'm happy to inform you that I
On Wed, Jan 27, 2021 at 02:32:35PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 27, 2021 at 12:04:26PM +0000, Mark Brown wrote:
> > The whole reason the driver is in the staging tree is that Mauro has a
> > requirement to do things in a way that preserves history and so won
On Wed, Jan 27, 2021 at 09:57:40AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 26, 2021 at 06:11:24PM +0000, Mark Brown wrote:
> > > Do you need a tag to pull from?
> > It'd be nice but not essential.
> Why do you want/need this? Having these changes in your tree
On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 26, 2021 at 05:57:52PM +0000, Mark Brown wrote:
> > Is there a branch we can pull from?
> Once 0-day passes, you can pull from my staging-testing branch from
> staging.git on git.kernel.org if you wa
On Tue, Jan 26, 2021 at 06:54:57PM +0100, Greg Kroah-Hartman wrote:
> I've applied the first 13 patches, except for patch 3, as that did not
> apply, to my tree, thanks.
Is there a branch we can pull from?
signature.asc
Description: PGP signature
___
On Wed, Jan 20, 2021 at 12:02:44AM +0100, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > Now that the driver has been converted to regmap these are just
> > duplicates of the regmap helpers. You may also be able to use them for
> > the disable() and is_enabled()
On Tue, Jan 19, 2021 at 05:10:45PM +0100, Mauro Carvalho Chehab wrote:
> +static int hi6421_spmi_regulator_get_voltage_sel(struct regulator_dev *rdev)
> +{
> +static int hi6421_spmi_regulator_set_voltage_sel(struct regulator_dev *rdev,
> + unsigned int
On Tue, Jan 19, 2021 at 11:14:20AM +0100, Mauro Carvalho Chehab wrote:
> +int hi6421_spmi_pmic_read(struct hi6421_spmi_pmic *pmic, int reg)
> +{
> + struct spmi_device *pdev;
> + u8 read_value = 0;
> + u32 ret;
> +
> + pdev = to_spmi_device(pmic->dev);
> + if (!pdev) {
> +
On Mon, Jan 18, 2021 at 05:02:45PM +0100, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > If for some reason the PMIC is sufficiently fragile to need a delay
> > between enables it's not clear why the driver is doing it before
> > enabling rather than after,
On Mon, Jan 18, 2021 at 02:28:12PM +0100, Mauro Carvalho Chehab wrote:
> index f385146d2bd1..3b23ad56b31a 100644
> --- a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
> +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
> @@ -60,6 +60,8 @@ required:
On Tue, Dec 01, 2020 at 05:17:20PM +0300, Dmitry Osipenko wrote:
> 01.12.2020 16:57, Mark Brown пишет:
> > [1/1] regulator: Allow skipping disabled regulators in
> > regulator_check_consumers()
> > (no commit info)
> Could you please hold on this patch? It won&#x
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
__
On Thu, Nov 19, 2020 at 05:22:43PM +0300, Dmitry Osipenko wrote:
> 16.11.2020 16:33, Mark Brown пишет:
> > No, you are failing to understand the purpose of this code. To
> > reiterate unless the device supports operating with the supply
> > physically absent then the
On Tue, Nov 17, 2020 at 09:38:30AM +0100, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > This also appears to be missing a DT binding document, binding
> > documentation is required for anything with DT support.
> The DT binding is documented on patch 3/8, togeth
On Tue, Nov 17, 2020 at 09:08:22AM +0100, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > This probe code looks very different to other regulator drivers, this
> > alone should have been a warning that the driver needs some substantial
> > refactoring here. As
On Mon, Nov 16, 2020 at 01:59:30PM +0100, Mauro Carvalho Chehab wrote:
> This driver is ready for mainstream. Move it out of staging.
There's quite a few issues here, to be honest I'm disappointed some of
them weren't caught during staging review, this needs fairly substantial
work and there's si
On Sun, Nov 15, 2020 at 08:42:10PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 20:28, Mark Brown пишет:
> >> What should we do?
> > As I keep saying the consumer driver should be enumerating the voltages
> > it can set, if it can't find any and wants to continue then
On Fri, Nov 13, 2020 at 08:13:49PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 19:15, Mark Brown пишет:
> > My point here is that the driver shouldn't be checking for a dummy
> > regulator, the driver should be checking the features that are provided
> > to it by the re
On Fri, Nov 13, 2020 at 06:55:27PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 17:29, Mark Brown пишет:
> > It's not clear if it matters - it's more a policy decision on the part
> > of the driver about what it thinks safe error handling is. If it's not
> I
On Fri, Nov 13, 2020 at 01:37:01AM +0300, Dmitry Osipenko wrote:
> 12.11.2020 23:01, Mark Brown пишет:
> >> But it's not allowed to change voltage of a dummy regulator, is it
> >> intentional?
> > Of course not, we can't know if the requested new voltage is
On Thu, Nov 12, 2020 at 10:16:14PM +0300, Dmitry Osipenko wrote:
> 12.11.2020 20:16, Mark Brown пишет:
> > On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:
> >> Also, some device-trees won't have that regulator anyways because board
> >> schemati
On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:
> 11.11.2020 14:55, Mark Brown пишет:
> > On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
> >> I already changed that code to use regulator_get_optional() for v2.
> > That doesn't lo
On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
> 10.11.2020 23:32, Mark Brown пишет:
> >>> + if (!device_property_present(dc->dev, "core-supply"))
> >>> + return;
> >> This is a potentially heavy operation, so I think
On Tue, Nov 10, 2020 at 09:29:45PM +0100, Thierry Reding wrote:
> On Thu, Nov 05, 2020 at 02:44:08AM +0300, Dmitry Osipenko wrote:
> > + /*
> > +* Voltage scaling is optional and trying to set voltage for a dummy
> > +* regulator will error out.
> > +*/
> > + if (!device_property_p
you have projects that need funding for further
discussion and negotiation .
Regards,
Mark Johnson
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Him today.
Thanks and may God bless you.
David Mark
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
if you have projects that needs funding for further
discussion and negotiation with any of the companies that will be interested to
fund your project.
Regards,
Mark Johnson
___
devel mailing list
de...@linuxdriverproject.org
http
On Fri, Jun 12, 2020 at 09:07:24PM +0530, Vaibhav Agarwal wrote:
> On Thu, Jun 11, 2020 at 09:26:16AM +0100, Mark Brown wrote:
> > > Kindly suggest me the preferred way to follow on this thread.
> > This is effectively out of tree code, until someone submits it properly
>
On Wed, Jun 10, 2020 at 08:01:18PM +0200, Alexandre Belloni wrote:
> My point was that if we were to keep that driver, the goal would be to
> have it out of staging instead of simply making it compile.
Yes, definitely - that should be the goal for anything in staging.
signature.asc
Description:
On Wed, Jun 10, 2020 at 11:53:24PM +0530, Vaibhav Agarwal wrote:
> With patch#6 in this series, I'm proposing some of the (dummy) helper
> APIs required to link DAPM DAI widgets for the GB Audio modules
> added/removed dynamically.
> Eventually, I would like to propose relevant changes in snd-s
On Wed, Jun 10, 2020 at 10:58:24PM +0530, Vaibhav Agarwal wrote:
> The existing GB Audio codec driver is dependent on MSM8994 Audio driver.
> During the development stage, this dependency was configured due to
> various changes involved in MSM Audio driver to enable addtional codec
> card and some
ing again they can take a look at the git history.
Thanks for this, Alexandre.
Acked-by: Mark Greer
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Fri, May 08, 2020 at 01:43:07PM +0100, Jonathan Cameron wrote:
> Dan Carpenter wrote:
> > It feels like we should just make a devm_ version of regulator_enable().
> > Or potentially this is more complicated than it seems, but in that case
> > probably adding devm_add_action_or_reset() is more
aml renames;
> - file renames (still on txt format);
This seems like it should've been split up a bit. :/
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driver
On Wed, Dec 04, 2019 at 07:18:15AM +, Ardelean, Alexandru wrote:
> One example (for spi-cpha):
> if (of_property_read_u32(nc, "spi-cpha", &tmp) == 0) {
> spi->mode |= SPI_CPHA_OVERRIDE;
> if (tmp)
> spi->mode |= SPI_CPHA;
We could al
On Tue, Dec 03, 2019 at 04:51:54PM +, Jonathan Cameron wrote:
> If the driver picks a mode because that's what it says on the datasheet
> it prevents odd board configurations from working. The question
> becomes whether it makes sense in general to assume those odd board
> conditions don't ex
On Sun, Dec 01, 2019 at 11:40:32AM +, Jonathan Cameron wrote:
> +CC Mark as we probably need a more general view point on
> the question of whether SPI mode should be enforced by binding
> or in the driver.
Not sure I see the question here, I think I was missing a bit of
the con
> Cc: Alex Elder
> Cc: Vaibhav Agarwal
> Cc: Mark Greer
> Cc: Viresh Kumar
> Cc: Rui Miguel Silva
> Cc: David Lin
> Cc: "Bryan O'Donoghue"
> Cc: greybus-...@lists.linaro.org
> Cc: de...@driverdev.osuosl.org
>
: Alex Elder
> Cc: Vaibhav Agarwal
> Cc: Mark Greer
> Cc: Viresh Kumar
> Cc: "Bryan O'Donoghue"
> Cc: greybus-...@lists.linaro.org
> Cc: de...@driverdev.osuosl.org
> Signed-off-by: Greg Kroah-Hartman
> ---
Acked-by: Mark Greer
On Wed, Jul 31, 2019 at 04:07:41AM -0700, kernelci.org bot wrote:
Today's -next fails to build an ARM allmodconfig due to:
> allmodconfig (arm, gcc-8) — FAIL, 1 error, 40 warnings, 0 section mismatches
>
> Errors:
> drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
> func
udio_manager_module *module, *next;
> - int is_empty = 1;
> + int is_empty;
>
> down_write(&modules_rwsem);
Reviewed-by: Mark Greer
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
rwal
I am sorry for not responding until now. For some strange reason, email
from this list are being delayed. I just got this today (April 30).
Thanks for the patch, Kangjie, and thanks for the review, Vaibhav.
And FWIW,
Reviewed-by: Mark Greer
Mark
--
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Dear,
I am Mr.Marck Csady a solicitor at law, i need your assistance to
represent my late client fund valued at $2.5 million dollars that his
bank wants to comfiscate, You bear the same last name with my late
client and he is also a national of your country.
Please if you are interested to assist
On Fri, Mar 22, 2019 at 03:02:54PM +0100, Stefan Roese wrote:
> On 21.03.19 15:25, Mark Brown wrote:
> > > + list_for_each_entry(t, &m->transfers, transfer_list)
> > > + if (t->speed_hz < speed)
> > > + speed = t->speed_hz;
On Thu, Mar 14, 2019 at 12:52:12PM +0100, Stefan Roese wrote:
This looks pretty good, a few trivial issues below but nothing major I
think.
> +config SPI_MT7621
> + tristate "MediaTek MT7621 SPI Controller"
> + depends on RALINK
> + help
> + This selects a driver for the MediaTe
I am Mrs Ann Mark, a born again christian and a widow and i want to make a
donation of $ 5.5 Million US Dollars to help orphans and widows and charitable
home in your country, and i assumed that you will be able to receive this fund
and use it to my wished to the needs in your country and i am
+ Sumit
Hi Sumit,
Do you have any thoughts on this patch?
It fixes a potential crash in on older kernel and I think limiting
begin/end_cpu_access to only apply cache maintenance when the buffer is
dma mapped makes sense from a logical perspective and performance
perspective.
On Wed, 6 Feb
On Mon, Feb 04, 2019 at 09:34:56AM +1100, NeilBrown wrote:
> It is extremely common in the kernel for a file to start
>// SPDX-License-Identifier.
> and to have that immediately followed by a comment lile:
> /*
> * .
> *
Yes, there was a lot of automated conversion AFAIC
On Fri, Feb 01, 2019 at 11:17:07AM +0100, Stefan Roese wrote:
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
> /*
> * spi-mt7621.c -- MediaTek MT7621 SPI controller driver
> *
Please convert the entire comment into a C++ comment so it looks more
intentional.
signature.asc
Descrip
On Fri, 4 Jan 2019, Skidanov, Alexey wrote:
>
>
> > -Original Message-
> > From: Liam Mark [mailto:lm...@codeaurora.org]
> > Sent: Friday, January 04, 2019 19:42
> > To: Skidanov, Alexey
> > Cc: Laura Abbott ; Greg KH ;
> > de...@
On Fri, 18 Jan 2019, Liam Mark wrote:
> On Fri, 18 Jan 2019, Andrew F. Davis wrote:
>
> > On 1/18/19 12:37 PM, Liam Mark wrote:
> > > The ION begin_cpu_access and end_cpu_access functions use the
> > > dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to p
On Mon, 21 Jan 2019, Brian Starkey wrote:
> Hi,
>
> Sorry for being a bit sporadic on this. I was out travelling last week
> with little time for email.
>
> On Fri, Jan 18, 2019 at 11:16:31AM -0600, Andrew F. Davis wrote:
> > On 1/17/19 7:11 PM, Liam Mark wrote:
&
On Tue, 22 Jan 2019, Andrew F. Davis wrote:
> On 1/21/19 4:12 PM, Liam Mark wrote:
> > On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> >
> >> On Mon, Jan 21, 2019 at 11:44:10AM -0800, Liam Mark wrote:
> >>> The main use case is for allowing clients to pass
On Tue, 22 Jan 2019, Andrew F. Davis wrote:
> On 1/21/19 4:18 PM, Liam Mark wrote:
> > On Mon, 21 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/21/19 2:20 PM, Liam Mark wrote:
> >>> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
> >>>
> >>&
On Mon, 21 Jan 2019, Brian Starkey wrote:
> Hi Liam,
>
> On Fri, Jan 18, 2019 at 10:37:47AM -0800, Liam Mark wrote:
> > Add support for configuring dma mapping attributes when mapping
> > and unmapping memory through dma_buf_map_attachment and
> > dma_buf_unmap_attac
On Mon, 21 Jan 2019, Andrew F. Davis wrote:
> On 1/21/19 2:20 PM, Liam Mark wrote:
> > On Mon, 21 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/21/19 1:44 PM, Liam Mark wrote:
> >>> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> >>>
> >>
On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> On Mon, Jan 21, 2019 at 12:20:42PM -0800, Liam Mark wrote:
> > I have left this to clients, but if they own the buffer they can have the
> > knowledge as to whether CPU access is needed in that use case (example for
> > post-p
On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> On Mon, Jan 21, 2019 at 11:44:10AM -0800, Liam Mark wrote:
> > The main use case is for allowing clients to pass in
> > DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance
> > which happens in dma_b
On Mon, 21 Jan 2019, Andrew F. Davis wrote:
> On 1/21/19 1:44 PM, Liam Mark wrote:
> > On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> >
> >> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
> >>>> And who is going to decide which ones to pas
On Fri, 18 Jan 2019, Andrew F. Davis wrote:
> On 1/17/19 7:11 PM, Liam Mark wrote:
> > On Thu, 17 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/16/19 4:54 PM, Liam Mark wrote:
> >>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
> >>>
> >&
On Mon, 21 Jan 2019, Andrew F. Davis wrote:
> On 1/18/19 3:43 PM, Liam Mark wrote:
> > On Fri, 18 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/17/19 7:04 PM, Liam Mark wrote:
> >>> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
> >>>
> >>&
On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
> > > And who is going to decide which ones to pass? And who documents
> > > which ones are safe?
> > >
> > > I'd much rather have explicit, well documented dma-buf flags that
> > > migh
On Fri, 18 Jan 2019, Andrew F. Davis wrote:
> On 1/17/19 7:04 PM, Liam Mark wrote:
> > On Thu, 17 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/16/19 4:48 PM, Liam Mark wrote:
> >>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
> >>>
> >>&
On Fri, 18 Jan 2019, Laura Abbott wrote:
> On 1/18/19 10:37 AM, Liam Mark wrote:
> > Add support for configuring dma mapping attributes when mapping
> > and unmapping memory through dma_buf_map_attachment and
> > dma_buf_unmap_attachment.
> >
> > Signed-off-by:
On Fri, 18 Jan 2019, Andrew F. Davis wrote:
> On 1/18/19 12:37 PM, Liam Mark wrote:
> > The ION begin_cpu_access and end_cpu_access functions use the
> > dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
> > maintenance.
> >
> > Curren
been
accessed by the CPU.
Signed-off-by: Liam Mark
---
drivers/staging/android/ion/ion.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 1fe633a7fdba..0aae845b20ba 100644
--- a/drivers/staging/androi
("staging: android: ion: Call dma_map_sg for syncing and
mapping")
Signed-off-by: Liam Mark
---
drivers/staging/android/ion/ion.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android
Fixes: 2a55e7b5e544 ("staging: android: ion: Call dma_map_sg for syncing and
mapping")
Signed-off-by: Liam Mark
---
drivers/staging/android/ion/ion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/
Add support for configuring dma mapping attributes when mapping
and unmapping memory through dma_buf_map_attachment and
dma_buf_unmap_attachment.
Signed-off-by: Liam Mark
---
include/linux/dma-buf.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/dma-buf.h b/include/linux
Some stability changes to improve ION robustness and a perf related
change to make it easier for clients to avoid unnecessary cache
maintenance, such as when buffers are clean and haven't had any CPU
access.
Liam Mark (4):
staging: android: ion: Support cpu access during dma_buf_d
On Thu, 17 Jan 2019, Andrew F. Davis wrote:
> On 1/16/19 4:54 PM, Liam Mark wrote:
> > On Wed, 16 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/16/19 9:19 AM, Brian Starkey wrote:
> >>> Hi :-)
> >>>
> >>> On Tue, Jan 15, 2019 at 12:4
On Thu, 17 Jan 2019, Andrew F. Davis wrote:
> On 1/16/19 4:48 PM, Liam Mark wrote:
> > On Wed, 16 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/15/19 1:05 PM, Laura Abbott wrote:
> >>> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
> >>>> On 1/
On Wed, 16 Jan 2019, Andrew F. Davis wrote:
> On 1/16/19 9:19 AM, Brian Starkey wrote:
> > Hi :-)
> >
> > On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
> >> On 1/15/19 12:38 PM, Andrew F. Davis wrote:
> >>> On 1/15/19 11:45 AM, L
On Wed, 16 Jan 2019, Andrew F. Davis wrote:
> On 1/15/19 1:05 PM, Laura Abbott wrote:
> > On 1/15/19 10:38 AM, Andrew F. Davis wrote:
> >> On 1/15/19 11:45 AM, Liam Mark wrote:
> >>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
> >>>
> >>>>
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
> On 1/14/19 11:13 AM, Liam Mark wrote:
> > On Fri, 11 Jan 2019, Andrew F. Davis wrote:
> >
> >> Buffers may not be mapped from the CPU so skip cache maintenance here.
> >> Accesses from the CPU to a cached heap should
On Fri, 11 Jan 2019, Andrew F. Davis wrote:
> Buffers may not be mapped from the CPU so skip cache maintenance here.
> Accesses from the CPU to a cached heap should be bracketed with
> {begin,end}_cpu_access calls so maintenance should not be needed anyway.
>
> Signed-off-by: Andrew F. Davis
> -
On Tue, 18 Dec 2018, Alexey Skidanov wrote:
> >>> I was wondering if we could re-open the discussion on adding support to
> >>> ION for dma_buf_vmap.
> >>> It seems like the patch was not taken as the reviewers wanted more
> >>> evidence of an upstream use case.
> >>>
> >>> Here would be my upst
On Sun, 16 Dec 2018, Alexey Skidanov wrote:
>
>
> On 12/16/18 7:20 AM, Liam Mark wrote:
> > On Tue, 6 Feb 2018, Alexey Skidanov wrote:
> >
> >>
> >>
> >> On 02/07/2018 01:56 AM, Laura Abbott wrote:
> >>> On 01/31/2018 10:10 PM, Alexe
On Tue, 6 Feb 2018, Alexey Skidanov wrote:
>
>
> On 02/07/2018 01:56 AM, Laura Abbott wrote:
> > On 01/31/2018 10:10 PM, Alexey Skidanov wrote:
> >>
> >> On 01/31/2018 03:00 PM, Greg KH wrote:
> >>> On Wed, Jan 31, 2018 at 02:03:42PM +0200, Alexey Skidanov wrote:
> Any driver may access sha
On Wed, 28 Nov 2018, Brian Starkey wrote:
> Hi Liam,
>
> On Tue, Nov 27, 2018 at 10:46:07PM -0800, Liam Mark wrote:
> > On Tue, 27 Nov 2018, Brian Starkey wrote:
> >
> > > Hi Liam,
> > >
> > > On Mon, Nov 26, 2018 at 08:59:44PM -0800, Liam Mark w
On Tue, 27 Nov 2018, Brian Starkey wrote:
> Hi Liam,
>
> On Mon, Nov 26, 2018 at 08:59:44PM -0800, Liam Mark wrote:
> > On Tue, 20 Nov 2018, Brian Starkey wrote:
> >
> > > Hi Liam,
> > >
> > > I'm missing a bit of context here, but I did re
hich
> certainly seem to be related to what you're trying to fix here.
>
> On Thu, Nov 01, 2018 at 03:15:06PM -0700, Liam Mark wrote:
> >Based on the suggestions from Laura I created a first draft for a change
> >which will attempt to ensure that uncached mappings are onl
On Fri, 2 Nov 2018, John Stultz wrote:
> On Thu, Nov 1, 2018 at 3:15 PM, Liam Mark wrote:
> > Based on the suggestions from Laura I created a first draft for a change
> > which will attempt to ensure that uncached mappings are only applied to
> > ION memory who's cac
apping.
Please let me know if this is heading in the right direction and if there
are any concerns.
Signed-off-by: Liam Mark
---
drivers/staging/android/ion/ion.c | 146 +-
drivers/staging/android/ion/ion.h | 9 +++
2 files changed, 152 insertions(+), 3 del
On 10/1/18 12:49 PM, Lidza Louina wrote:
On Mon, Oct 1, 2018 at 8:09 AM Mark Hounschell <mailto:ma...@compro.net>> wrote:
On 9/28/18 3:59 PM, Lidza Louina wrote:
> I haven't done work on this driver in a long time. I looked up the
> devices, and they see
SI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: jsm
Kernel modules: jsm
Regards
Mark
___
devel mailing
On Sat, Jul 21, 2018 at 08:53:21AM +0200, Greg KH wrote:
> On Thu, Jul 19, 2018 at 10:43:18PM +0100, Mark Railton wrote:
> > Fixed a coding style issue
> >
> > Signed-off-by: Mark Railton
> > ---
> > drivers/staging/pi433/rf69.c | 3 ++-
> > 1 fi
Removed a commented out case statement
Signed-off-by: Mark Railton
---
drivers/staging/pi433/rf69.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 14826fb505dd..b2d69af6d3fe 100644
--- a/drivers/staging/pi433/rf69.c
+++ b
Fixed a coding style issue
Signed-off-by: Mark Railton
---
drivers/staging/pi433/rf69.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index 90280e9b006d..14826fb505dd 100644
--- a/drivers/staging/pi433/rf69.c
f or hypervisor page tables.
> + */
> + touch = READ_ONCE(*(char *)input);
> + dmb(sy);
> + }
> +
> + /* Let the caller sort it out. */
> + return -1;
AFAICT, callers of slow_virt_to_phys() don't check the
, "Invalid kcontrol count=%d for %s\n",
> w->ncontrols, w->name);
> return ret;
> }
Acked-by: Mark Greer
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote:
> The first 6 patches can be applied independently by subsystem
> maintainers.
> The last two patches depend on the first 6 patches, and are thus marked
> RFC.
Would it not make sense to try to apply everything en masse rather th
On Mon, Apr 02, 2018 at 04:26:49PM +0200, Robert Jarzmik wrote:
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.
Acked-by: Mark Brown
If there's no
n audio.h
> + * (Android media layer)
> + */
> enum {
> GBAUDIO_DEVICE_NONE = 0x0,
> /* reserved bits */
> --
> 1.9.1
Reviewed-by: Mark Greer
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
m specific
> symbol, or PCI.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
m specific
> symbol, or PCI.
Acked-by: Mark Brown
Thanks again for doing this work, it's really good to see!
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org
1 - 100 of 565 matches
Mail list logo
