On Mon, Oct 06, 2014 at 10:28:08PM -0700, Guenter Roeck wrote:
> pm_power_off is an implementation detail. Replace it with a more generic
> description of the driver's functionality.
>
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Signed-off-by: Guenter Roe
On Mon, Oct 06, 2014 at 10:28:09PM -0700, Guenter Roeck wrote:
> Replace reference to pm_power_off (which is an implementation detail)
> and replace it with a more generic description of the driver's functionality.
Acked-by: Andrew Lunn
Thanks
Andrew
>
> Cc: Rob Her
On Fri, 16 Feb 2018 09:13:27 -0800 Joe Perches wrote:
> On Fri, 2018-02-16 at 15:55 +0300, Dan Carpenter wrote:
> > On Fri, Feb 16, 2018 at 05:06:34PM +0530, Yash Omer wrote:
> > > This patch fix line should not end with open parenthesis found by
> > > checkpatch.plscript.
> > >
> > > Signed-of
EX_IF];
> +
> + err = devm_request_threaded_irq(dev, irq->msi_desc->irq,
> + ethsw_irq0_handler,
> + ethsw_irq0_handler_thread,
> + IRQF_NO_S
+ }
> + }
> +
> + return notifier_from_errno(err);
> +}
I could be missing something here, but don't you need to pass to
port_bridge_join() which bridge the port is joining. There can be
multiple bridges, so you need to ensure the port joins the correct
bridge.
brctl addif br1 lan3
Is there somewhere in the code which sets the scope for the flooding?
lan0 can flood to lan1, but it should not flood to lan2 or lan3, since
they are in a different bridge. I was expecting that
ethsw_port_set_flood() takes upper_dev, in order to configure which
ports it sho
> Hello Andrew,
>
> The current driver implementation uses only a single FDB for the switch,
> so it is not possible configure multiple flooding domains to accommodate
> ports partitioning.
Ah, O.K. Rather than break somebodies network by wrongly flooding, it
would be b
ver
> can be found in the associated README file.
Hi Greg
This code has much better quality than the usual stuff in staging. I
see no reason not to merge it.
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdrive
On Thu, Mar 15, 2018 at 01:56:42PM +0300, Dan Carpenter wrote:
> On Thu, Mar 15, 2018 at 12:44:37AM +0100, Andrew Lunn wrote:
> > On Wed, Mar 14, 2018 at 10:55:52AM -0500, Razvan Stefanescu wrote:
> > > This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoC
ing at the code, i think you are changing the flow to become
read/modify/write, instead of just write, which is overwriting the
previously configured Priority Code Point?
Please try to add more details to your change logs, to help us
understand the change.
On Tue, 16 Jun 2020 11:43:11 -0400 Waiman Long wrote:
> As said by Linus:
>
> A symmetric naming is only helpful if it implies symmetries in use.
> Otherwise it's actively misleading.
>
> In "kzalloc()", the z is meaningful and an important part of what the
> caller wants.
>
> In "kz
Sehr geehrter Herr.
Entschuldigen Sie meine Stцrung; Mein Name ist Lieutenant Andrew Ferrara,
derzeit bin ich im aktiven Dienst in Afghanistan. Bitte, muss ich eine verdeckt
Business-Angebot, die von gegenseitigem Nutzen fьr uns beide werden.
Am Samstag 20. Juli, meine Kollegen und ich
Sehr geehrter Herr.
Entschuldigen Sie meine Stцrung; Mein Name ist Lieutenant Andrew Ferrara,
derzeit bin ich im aktiven Dienst in Afghanistan. Bitte, muss ich eine verdeckt
Business-Angebot, die von gegenseitigem Nutzen fьr uns beide werden.
Am Samstag 20. Juli, meine Kollegen und ich
My name is Dr Andrew Cardwell. I'm working as a Marketing
Consultant/Supplier with an animal Farm Company here in
England. I just glanced through your profile and decided to contact you.
I wish to seek your consent for an urgent business dealing with my
company. kindly get back to me for
The heap name can be used for debugging but otherwise does not seem
to be required and no other part of the code will fail if left NULL
except here. We can make it required and check for it at some point,
for now lets just prevent this from causing a NULL pointer exception.
Signed-off-by: Andrew
When enabled the helpers functions for creating carveout and chunk heaps
should have declarations in the ION header.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.h | 33 +++
1 file changed, 33 insertions(+)
diff --git a/drivers/staging/android
The base address is not used anywhere and tracked by the pool
allocator. No need to store this anymore.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion_chunk_heap.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/android/ion
Various cleanups have removed the use of some headers in ION, remove
these here.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.c | 3 ---
drivers/staging/android/ion/ion_carveout_heap.c | 4 ++--
drivers/staging/android/ion/ion_chunk_heap.c| 3 +--
3 files
The file ion-ioctl.c is now much to small and tightly integrated
with the main ion.c file to justify keeping it separate. Merge
this file.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/Makefile| 2 +-
drivers/staging/android/ion/ion-ioctl.c | 86
elements from this struct, just convert
these to get supplied these values from the heap registrar directly.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.h | 23 ---
.../staging/android/ion/ion_carveout_heap.c | 12 --
drivers/staging
Since we use CMA APIs directly there is no device nor private heaps data,
drop this comment.
Fixes: 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion_cma_heap.c | 4
1 file changed, 4 deletions(-)
di
The base address is not used anywhere and tracked by the pool
allocator. No need to store this anymore.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion_carveout_heap.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/staging/android/ion
This struct is no longer documented correctly, fix this.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index 2ef78c951a6b
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
---
drivers/staging/android/ion/ion.c | 7 ---
1
This function is empty of real function and can be replaced with
_IOC_DIR().
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion-ioctl.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers
The filenames in headers add nothing are often wrong after moves, lets
drop them here and add a little description of the files contents.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.c | 2 +-
drivers/staging/android/ion/ion.h | 2 +-
drivers
the secure/unmapped heap from Linaro for
the OP-TEE SDP implementation, this was re-written to match
the carveout heap helper code.
Suggested-by: Etienne Carriere
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/Kconfig | 10 ++
drivers/staging/android/ion/Makefile
needed afterall..
Thanks,
Andrew
Andrew F. Davis (14):
staging: android: ion: Add proper header information
staging: android: ion: Remove empty ion_ioctl_dir() function
staging: android: ion: Merge ion-ioctl.c into ion.c
staging: android: ion: Remove leftover comment
staging: an
Add white-space for easier reading and remove some where it does
not belong. No functional changes, they just bug me..
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion_carveout_heap.c | 1 +
drivers/staging/android/ion/ion_chunk_heap.c| 2 +-
drivers/staging/android/ion
On 1/14/19 8:32 PM, Laura Abbott wrote:
> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>> The "unmapped" heap is very similar to the carveout heap except
>> the backing memory is presumed to be unmappable by the host, in
>> my specific case due to firewalls. This m
On 1/14/19 8:39 PM, Laura Abbott wrote:
> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>> Hello all,
>>
>> This is a set of (hopefully) non-controversial cleanups for the ION
>> framework and current set of heaps. These were found as I start to
>> familiarize mys
On 1/15/19 11:45 AM, Liam Mark 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 he
On 1/15/19 12:38 PM, Andrew F. Davis wrote:
> On 1/15/19 11:45 AM, Liam Mark 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:
>>>>
>>&g
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 be bracketed with
>> {begin,end}_cpu_access calls so maintena
On 1/15/19 12:58 PM, Laura Abbott wrote:
> On 1/15/19 9:47 AM, Andrew F. Davis wrote:
>> On 1/14/19 8:39 PM, Laura Abbott wrote:
>>> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>>>> Hello all,
>>>>
>>>> This is a set of (hopefully) non-controv
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 1/14/19 11:13 AM, Liam Mark wrote:
>>>>> On Fri, 11 Jan
On 1/15/19 1:11 PM, Laura Abbott wrote:
> On 1/15/19 10:43 AM, Laura Abbott wrote:
>> On 1/15/19 7:58 AM, Andrew F. Davis wrote:
>>> On 1/14/19 8:32 PM, Laura Abbott wrote:
>>>> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>>>>> The "unmapped
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, Liam Mark wrote:
>>>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
On 1/16/19 9:28 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
>> The heap name can be used for debugging but otherwise does not seem
>> to be required and no other part of the code will fail if left NULL
>>
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/15/19 11:45 AM, Liam Mark wrote:
>>>>> On Tue, 15 Jan 2019, A
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:40:16PM -0600, Andrew F. Davis wrote:
>>>> On 1/15/19 12:38 PM, And
On 1/18/19 3:59 AM, Greg Kroah-Hartman wrote:
> On Fri, Jan 11, 2019 at 12:05:21PM -0600, Andrew F. Davis wrote:
>> When enabled the helpers functions for creating carveout and chunk heaps
>> should have declarations in the ION header.
>
> Why? No one calls these from what I
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 1/15/19 1:05 PM, Laura Abbott wrote:
>>>>> On 1/15/19
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 1/16/19 9:19 AM, Brian Starkey wrote:
>>>>> Hi :-)
>
a_sync_sg_for_cpu
>
The window for this seems really small, but it does seem technically
possible, good find. for what it's worth:
Acked-by: Andrew F. Davis
> Fix this by getting the ion_buffer lock before freeing the sg table memory.
>
> Fixes: 2a55e7b5e544 ("staging: andr
there, but DMA-BUF was
designed with late allocation in mind. I have a use-case I'm working on
that finally exercises this DMA-BUF functionality and I would like to
have it export through ION. This patch doesn't prevent that, but seems
like it is endorsing the the idea that bu
On 1/18/19 2:31 PM, Laura Abbott wrote:
> On 1/17/19 8:13 AM, 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
On 1/18/19 1:53 PM, Laura Abbott wrote:
> On 1/16/19 9:12 AM, Andrew F. Davis wrote:
>> On 1/16/19 9:28 AM, Brian Starkey wrote:
>>> Hi Andrew,
>>>
>>> On Fri, Jan 11, 2019 at 12:05:20PM -0600, Andrew F. Davis wrote:
>>>> The heap name can be used f
On 1/18/19 2:19 PM, Laura Abbott wrote:
> On 1/16/19 8:05 AM, Andrew F. Davis wrote:
>> On 1/15/19 12:58 PM, Laura Abbott wrote:
>>> On 1/15/19 9:47 AM, Andrew F. Davis wrote:
>>>> On 1/14/19 8:39 PM, Laura Abbott wrote:
>>>>> On 1/11/19 10:0
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 1/16/19 4:48 PM, Liam Mark wrote:
>>>>> On Wed, 16 Jan
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 pass? And who documents
which ones are safe?
I'd much rather have explicit, well doc
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 Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
>&
On 1/21/19 5:22 AM, 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 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 1/21/19 1:44 PM, Liam Mark wrote:
>>>>> On Mon, 21 Ja
e cost you are
trying to avoid?
In that case if you are mapping and unmapping so much that the little
CMO here is hurting performance then I would argue your usage is broken
and needs to be re-worked a bit.
Andrew
>
> Qualcomm Innovation Center, Inc. is a me
ittle different in each email, so I'd like to respond
to bits of both, I'll fix up the formatting.
> Also, adding Daniel Vetter to the mix, since he has been one of the
> core guys who shaped up dma-buf as it is today.
>
> On Tue, 22 Jan 2019 at 02:51, Andrew F. Davis w
over the DMA-BUF framework can clarify
>> original intentions here.
>>
>
> I suppose dma-buf as a framework can't know or decide what the exporter
> wants or can do - whether the exporter wants to use it for 'only
> zero-copy', or do some intel
ned-off-by: Andrew F. Davis
---
This also means we don't need to store the available heaps in a plist,
we only operation we care about is lookup, so a better data structure
should be chosen at some point, regular list or xarray maybe?
This is base on -next as to be on top of the other ta
On 1/23/19 11:11 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Wed, Jan 23, 2019 at 10:51:24AM -0600, Andrew F. Davis wrote:
>> On 1/22/19 11:33 AM, Sumit Semwal wrote:
>>> Hello everyone,
>>>
>>> Sincere apologies for chiming in a bit late here,
On 1/24/19 9:24 AM, Brian Starkey wrote:
> Hi Andrew,
>
> On Wed, Jan 23, 2019 at 01:28:35PM -0600, Andrew F. Davis wrote:
>> Previously the heap to allocate from was selected by a mask of allowed
>> heap types. This may have been done as a primitive form of constraint
>&
;)
Signed-off-by: Andrew F. Davis
---
This also means we don't need to store the available heaps in a plist,
we only operation we care about is lookup, so a better data structure
should be chosen at some point, regular list or xarray maybe?
This is base on -next as to be on top of the
On 1/29/19 5:44 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
rate over the details of each heap
pick the best heap for the job
request allocation from that heap (ioctl on ion_fd)
with per-heap devs we need some way to iterate all over heap devices in
a system, and extract details from each heap device. Maybe we leave
/dev/ion but it's
On 2/15/19 1:58 PM, John Stultz wrote:
> On Fri, Feb 15, 2019 at 11:22 AM Andrew F. Davis wrote:
>>
>> On 2/15/19 1:01 PM, John Stultz wrote:
>>> On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
>>>> On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wr
On 05/31/2016 02:47 PM, Luis de Bethencourt wrote:
> val is set to the value of ret right after ret is checked. If ret is not
> zero it goes to error_ret. So only value ret can have is zero, which makes
> the switch (val & 0x03) only match the case 0x00. Removing the switch and
> since val is only
Increase readability of code following the Kernel coding style by breaking long
lines and thus eliminating the checkpatch.pl warning.
Signed-off-by: Andrew Jye Shih Chuang
---
drivers/staging/speakup/main.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a
101 - 166 of 166 matches
Mail list logo
