Good Day,
I have a business proposal for you and it's 100% legal.
Barrister Andrew Tochaile.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Good Day,
I have a business proposal for you and it's 100% legal.
Barrister Andrew Tochaile.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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
be removed?
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Fixed a coding style issue.
Signed-off-by: Andrew Bridges
---
drivers/android/binder.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index b5117576792b..3241d233a12d 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
match a destination MAC address of xD:XX:XX:XX:XX:XX.
> /* Port received 0xd preamble */
> work->packet_ptr.s.addr += i;
> work->word1.len -= i + 4;
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
}
> + }
> +
> if (!dev->netdev_ops) {
> free_netdev(dev);
> } else if (register_netdev(dev) < 0) {
> --
> 2.10.2
I would also expect a call to of_phy_der
dev_ops) {
> free_netdev(dev);
Setting dev->netdev_ops to NULL to indicate an error is pretty
odd. But this is staging. How about cleaning this
up. of_phy_register_fixed_link() returns an -errno which you should
return.
Andrew
_
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
rchitecture support, you might want to look at how the dpaa2
drivers have evolved, what they got wrong, what they got right. How is
your hardware similar and different. And look at what parts of dpaa2
have moved out of staging, and maybe consider that code as a good
model to follow.
Andrew
___
1 cards, and an
E1 card which is not part of DAHDI.
Given how much of this is out of tree, i would understand if you
eventually decide to remove this HDLC code.
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverde
this is a switch driver, please
ensure you Cc: the usual suspects for switch drivers.
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
he machine. A WARN() and a return of -EINVAL would be
better.
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
to various patches, however for all the patches
you can add:
Reviewed-by: Andrew Murray
>
> Changes in v3:
> - Updated commits description.
> - Refactored "< PCI_ROM_RESOURCE" with "< PCI_STD_NUM_BARS" in loops.
> - Refactored "<= BAR_5"
else
> + priv->phy_mode = PHY_INTERFACE_MODE_RGMII;
Humm, that is unique, as far as i know. Every other MAC driver uses
of_get_phy_mode() to get the value out of device tree. The proprietary
delay values can then be used to fine tune the basic delay setting
read from DT.
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Wed, 27 Feb 2019 13:32:14 +0800 Dave Young wrote:
> This series have been in -next for some days, could we get this in
> mainline?
It's been in -next for two months?
> Andrew, do you have plan about them, maybe next release?
They're all reviewed except for "xe
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
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
> See the patch about all of this from Thomas on lkml yesterday for
> why this is the case.
Hi Greg
Thanks for the info. I had not seen this, and i guess other have not
as well. So here is a link to the patch.
https://lkml.org/lkml/2019/1/28/1975
"GPL v2" [GNU Public License v2]
So the SPDX string probably does not match the MODULE_LICENSE.
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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
;)
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/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
>&
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,
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
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
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
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
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
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 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 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/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/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 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: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
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
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
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 :-)
>
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/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/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/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 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 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/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/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 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/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: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/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/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/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
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
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
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
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
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 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
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
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
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
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
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 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
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 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
etting the devicetree GIT tree or something like that.
>
> Actually, this was rebased onto linux-next. Which tree do you want me
> to rebase onto?
Hi Sergio
It should be based on net-next. However, that is closed now, so please
wait until it reopens in about two wee
.read8 = ksz_i2c_read8,
> + .read16 = ksz_i2c_read16,
> + .read24 = ksz_i2c_read24,
> + .read32 = ksz_i2c_read32,
> + .write8 = ksz_i2c_write8,
> + .write16 = ksz_i2c_write16,
> + .write24 = ksz_i2c_write24,
> + .write32 = ksz_i2c_write32,
> +
> I'll change these two to to get memory from kernel allocators instead
> of using the stack. Thanks for let me know this.
There appear to be other cases as well. Please review the whole
driver.
Thanks
Andrew
___
de
ksz9897: ksz9897@0 {
Hi Sergio
You should use a generic name here. Plus the @X needs to be the same as the reg
value.
So switch: ksz9897@5f.
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
; + msg[1].len = len;
> + msg[1].buf = val;
You potentially have the same issue with val.
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hi
I would like to make use of an ISA card which generates IRQ 5
preferably using user-space code only, if possible.
Does anybody know of any example code using uio_pdrv_genirq
which could be adapted for this purpose?
Or, does anyone have a simple example kernel module?
Thanks!
Andrew
, it's mainly an android patch so I suggest this be taken via the
android tree.
Acked-by: Andrew Morton
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Wed, 7 Nov 2018 01:48:12 + chouryzhou(周威) wrote:
> > > --- a/ipc/namespace.c
> > > +++ b/ipc/namespace.c
> > > @@ -56,6 +56,9 @@ static struct ipc_namespace *create_ipc_ns(struct
> > user_namespace *user_ns,
> > > ns->ucounts = ucounts;
> > >
> > > err = mq_init_ns(ns);
> >
On Mon, 29 Oct 2018 06:18:11 + chouryzhou(周威)
wrote:
> We are working for running android in container, but we found that binder is
> not isolated by ipc namespace. Since binder is a form of IPC and therefore
> should
> be tied to ipc namespace. With this patch, we can run more than one a
On Mon, 05 Nov 2018 15:12:27 +0530 Arun KS wrote:
> On 2018-10-22 16:03, Arun KS wrote:
> > On 2018-10-19 13:37, Michal Hocko wrote:
> >> On Thu 18-10-18 19:18:25, Andrew Morton wrote:
> >> [...]
> >>> So this patch needs more work, yes?
> >>
&g
On Thu, 11 Oct 2018 09:55:03 +0200 Michal Hocko wrote:
> > > > > This is now not called anymore, although the xen/hv variants still do
> > > > > it. The function seems empty these days, maybe remove it as a followup
> > > > > cleanup?
> > > > >
> > > > > > - __online_page_increment_counters(pag
p; ETHERNET
With the move out of staging, i don't think these two are required.
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
se the space. But you have to be sure the
current code is correctly ignoring it and setting it to zero.
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
unused. rtc.c
does nothing with interrupts for example. Do you plan to make use of
this extra code? Or can it be removed leaving just what is needed?
struct dprtc_cmd_get_irq - Putting pad at the beginning of a struct
seems very odd. And it is not the only example.
Andrew
___
ality.
If the patch just lists a rename, not actually code, i cannot review
it, so i will just NACK it. We need to see the code.
Once the code has been reviewed and has all the needed Acked-by:, then
-M could be used. But this driver is not that far yet.
Thanks
Andrew
_
, "Failed to set link interrupt, fall back
> to polling\n");
> + priv->poll_thread = kthread_run(poll_link_state, priv,
> + "%s_poll_link", net_dev->name);
> + if (IS_ERR(priv->poll_thread)) {
> + netdev_err(net_dev, "Error starting polling thread\n");
> + goto err_poll_thread;
> + }
> + priv->do_link_poll = true;
> + }
Probably the correct place to register the netdev is here.
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
On Thu, 19 Jul 2018 23:17:53 +0800 Baoquan He wrote:
> Hi Andrew,
>
> On 07/18/18 at 03:33pm, Andrew Morton wrote:
> > On Wed, 18 Jul 2018 10:49:44 +0800 Baoquan He wrote:
> >
> > > For kexec_file loading, if kexec_buf.top_down is 'true', the memory w
On Wed, 18 Jul 2018 10:49:44 +0800 Baoquan He wrote:
> For kexec_file loading, if kexec_buf.top_down is 'true', the memory which
> is used to load kernel/initrd/purgatory is supposed to be allocated from
> top to down. This is what we have been doing all along in the old kexec
> loading interface
On Tue, 24 Apr 2018 16:23:04 +0200 Christoph Hellwig wrote:
> On Thu, Apr 19, 2018 at 09:57:50PM +0300, Alexey Dobriyan wrote:
> > > git://git.infradead.org/users/hch/misc.git proc_create
> >
> >
> > I want to ask if it is time to start using poorman function overloading
> > with _b_c_e().
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
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 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
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
> 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
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
+ }
> + }
> +
> + 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.
EX_IF];
> +
> + err = devm_request_threaded_irq(dev, irq->msi_desc->irq,
> + ethsw_irq0_handler,
> + ethsw_irq0_handler_thread,
> + IRQF_NO_S
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
_change_mtu(struct net_device *netdev, int new_mtu)
> +{
> + struct bgx_port_priv *priv = bgx_port_netdev2priv(netdev);
> + int max_frame;
> +
> + if (new_mtu < 60 || new_mtu > 65392) {
See dev_set_mtu(). If you have done your initialisation correctly, this
won't happen.
&
;s fine.
There are also :
uapi/linux/ethtool.h:#define SPEED_10 10
uapi/linux/ethtool.h:#define SPEED_100 100
uapi/linux/ethtool.h:#define SPEED_1000 1000
uapi/linux/ethtool.h:#define SPEED_11
uapi/linux/ethtool.h:#define SPEED_10 10
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
clear. Cut the rest.
Thanks
Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
";
> + reg = <0x00011800 0xe000 0x 0x0100>;
Hi David
In the probe function we have:
+ reg = of_get_property(pdev->dev.of_node, "reg", NULL);
+ addr = of_translate_address(pdev->dev.of_node, reg);
+ interface = (addr >&
1 - 100 of 166 matches
Mail list logo
