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
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
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 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
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 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
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 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
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
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
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
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
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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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, 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 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, 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 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 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 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 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
("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
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
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
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/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 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 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 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/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 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, 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, 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, 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 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 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 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 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 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, 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 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
+ 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 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
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;
: 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
> 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
>
user land apps, delivered with
the driver package, also used it. They probably had different people
working on the kernel and user land side.
Mark
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/lis
On Mon, Jan 12, 2015 at 10:05:49AM -0600, Rob Herring wrote:
> On Sun, Jan 11, 2015 at 10:29 AM, atull wrote:
> > Previous uses of the firmware layer has been to use it to load once after
> > bootup; this is different since some use cases will want to switch out
> > the FPGA image. If someone wa
On Thu, Jan 15, 2015 at 11:36:17AM +, One Thousand Gnomes wrote:
> yes - there is a model for this in Linux already. Some of the audio
> subsystems have "firmware" files distributed which are actually a
> structured file that userspace parses to get a real set of firmware for
> the controller
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
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
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
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
On Tue, Sep 26, 2017 at 02:07:05PM +0200, Benjamin Gaignard wrote:
> version 4:
> - add a configuration flag to switch between legacy Ion misc device
> and one device per heap version.
Should this be a switch or should it just be enabling and disabling the
legacy device with the per heap ones a
On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote:
> Thinking about this a bit more, I'm not 100% sure if this
> will allow the security rules we want. Heap ids are assigned
> dynamically and therefore so will the /dev/ionX designation.
> From my understanding, security rules like selin
On Tue, Oct 03, 2017 at 04:08:30PM -0700, Sandeep Patil wrote:
> It is entirely possible and easy in android/ueventd to create those nodes
> under "/dev/ion/". (assuming the heap 'subsystem' for these new devices will
> point to 'ion').
The reason I didn't say /dev/ion/foo initially is that if p
On Thu, Oct 05, 2017 at 02:56:54PM +0200, Sebastian Andrzej Siewior wrote:
> rwlock.h should not be included directly. Instead linux/splinlock.h
> should be included. One thing it does is to break the RT build.
>
> Cc: Vaibhav Agarwal
> Cc: Mark Greer
> Cc: Johan Hovold
>
On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
> Anyway, to move this forward I think we need to see a proof of concept
> of using selinux to protect access to specific heaps.
Aren't Unix permissions enough with separate files or am I
misunderstanding what you're looking to see a p
On Mon, Oct 09, 2017 at 05:10:37PM -0700, Laura Abbott wrote:
> On 10/09/2017 03:08 PM, Mark Brown wrote:
> > On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
> >> Anyway, to move this forward I think we need to see a proof of concept
> >> of using s
On Tue, Oct 31, 2017 at 12:03:35PM -0700, Laura Abbott wrote:
> I'm not a fan of the platform bus but I have mixed feelings about
> creating a dedicated bus type. I guess if we really need a bus
> type we can do it later?
There was a discussion a while ago in the context of I2C/SPI MFDs
which con
On Thu, Nov 02, 2017 at 11:44:07AM +0100, Greg KH wrote:
> On Tue, Oct 31, 2017 at 07:11:53PM +0000, Mark Brown wrote:
> > There was a discussion a while ago in the context of I2C/SPI MFDs
> > which concluded that if you need a bus and it's going to be effectively
> >
Cc: Johan Hovold
> Cc: Alex Elder
> Cc: Greg Kroah-Hartman
> Cc: Vaibhav Hiremath
> Cc: Vaibhav Agarwal
> Cc: Mark Greer
> Cc: Viresh Kumar
> Cc: Rui Miguel Silva
> Cc: David Lin
> Cc: "Bryan O'Donoghue"
> Cc: Thomas Gleixner
> Cc: Kate Stewa
text was removed.
>
> Cc: Vaibhav Hiremath
> Cc: Johan Hovold
> Cc: Alex Elder
> Cc: Greg Kroah-Hartman
> Cc: Vaibhav Agarwal
> Cc: Mark Greer
> Cc: Viresh Kumar
> Cc: Rui Miguel Silva
> Cc: David Lin
> Cc: "Bryan O&#x
On Mon, Nov 27, 2017 at 05:12:23PM +0100, Daniel Vetter wrote:
> commit model ftw, we have 400+ patches for 4.16 already merged and tested
> and all ready, right when -rc1 gets tagged. Makes the merge window the
> most relaxed time of all, because all the other maintainers are drowning
> and wont
On Tue, Nov 28, 2017 at 02:32:17PM +0100, Greg KH wrote:
> Where is the documentation for the new sysfs files and the new ioctl
Didn't see any sysfs files in there?
> call you added? What did you do to test this out? Where are the AOSP
> patches to use this? Happen to have a VTS test for it?
On Tue, Nov 28, 2017 at 06:08:22PM +0100, Greg KH wrote:
> On Tue, Nov 28, 2017 at 04:26:20PM +0000, Mark Brown wrote:
> > On Tue, Nov 28, 2017 at 02:32:17PM +0100, Greg KH wrote:
> > > call you added? What did you do to test this out? Where are the AOSP
> > > patc
On Tue, Nov 28, 2017 at 06:28:38PM +0100, Greg KH wrote:
> On Tue, Nov 28, 2017 at 05:12:23PM +0000, Mark Brown wrote:
> > I think it's reasonable to ask for userspace, I'm querying why it needs
> > to specifically be Android.
> Does anyone other than Android use thi
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
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
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
ng by
the compatible string and general shape of the code), and the original
ccp-platform.c is no longer built.
Shouldn't ccp-platform.c be deleted by this patch?
Thanks,
Mark.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Fixed a coding style issue.
Signed-off-by: Mark Stenglein
---
drivers/staging/wlan-ng/hfa384x.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 5f1851c85f12..f19984747b1e 100644
--- a/drivers/staging/wlan-ng
On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
> No one gave a thing about android in upstream, so Greg KH just dumped it
> all into staging/android/. We've discussed ION a bunch of times, recorded
> anything we'd like to fix in staging/android/TODO, and Laura's patch
> series here
All,
Thanks for the feedback. Trying to introduce myself and in retrospect
this seems to be a fairly non-productive way to go about it. Apologies
for any time lost.
Best,
Mark Stenglein
On Tue, Mar 07, 2017 at 08:31:13PM +0300, Dan Carpenter wrote:
> On Sun, Mar 05, 2017 at 09:09:12PM -0
On Mon, Mar 13, 2017 at 10:54:33AM +, Brian Starkey wrote:
> On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote:
> > Another point is how can we put secure rules (like selinux policy) on
> > heaps since all the allocations
> > go to the same device (/dev/ion) ? For example, unti
1 - 100 of 565 matches
Mail list logo
