[PATCH] [PATCH 1/1] staging: erofs: Add function comment for erofs/super.c
This patch adds functions comment for file erofs/super.c in
sphinx format.
Signed-off-by: Arshad Hussain
---
drivers/staging/erofs/super.c | 135 --
1 file changed, 131 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
index 15c784fba879..60bfc3e8db7a 100644
--- a/drivers/staging/erofs/super.c
+++ b/drivers/staging/erofs/super.c
@@ -30,6 +30,11 @@ static void init_once(void *ptr)
inode_init_once(>vfs_inode);
}
+/**
+ * erofs_init_inode_cache(): Create & initialize inode cache
+ *
+ * Returns: 0 on Success. Errno Otherwise.
+ */
static int __init erofs_init_inode_cache(void)
{
erofs_inode_cachep = kmem_cache_create("erofs_inode",
@@ -39,11 +44,21 @@ static int __init erofs_init_inode_cache(void)
return erofs_inode_cachep != NULL ? 0 : -ENOMEM;
}
+/**
+ * erofs_exit_inode_cache(): Destroy inode cache
+ */
static void erofs_exit_inode_cache(void)
{
kmem_cache_destroy(erofs_inode_cachep);
}
+/**
+ * alloc_inode(): Allocate and initialize inode
+ *
+ * @sb: VFS superblock structure
+ *
+ * Returns: Pointer to inode structure
+ */
static struct inode *alloc_inode(struct super_block *sb)
{
struct erofs_vnode *vi =
@@ -57,6 +72,11 @@ static struct inode *alloc_inode(struct super_block *sb)
return >vfs_inode;
}
+/**
+ * i_callback(): Release slab Memory
+ *
+ * @head: RCU callback structure
+ */
static void i_callback(struct rcu_head *head)
{
struct inode *inode = container_of(head, struct inode, i_rcu);
@@ -71,11 +91,23 @@ static void i_callback(struct rcu_head *head)
kmem_cache_free(erofs_inode_cachep, vi);
}
+/**
+ * destroy_inode(): Release Inode Resources allocated by alloc_inode()
+ *
+ * @inode: VFS Inode structure
+ */
static void destroy_inode(struct inode *inode)
{
call_rcu(>i_rcu, i_callback);
}
+/**
+ * superblock_read(): Read superblock into buffer
+ *
+ * @sb: VFS Superblock structure
+ *
+ * Returns: 0 on Success. Errno otherwise
+ */
static int superblock_read(struct super_block *sb)
{
struct erofs_sb_info *sbi;
@@ -230,6 +262,14 @@ static match_table_t erofs_tokens = {
{Opt_err, NULL}
};
+/**
+ * parse_options(): Parse and set additional mount option for erofs
+ *
+ * @sb: VFS superblock structure
+ * @options: Mount options
+ *
+ * Returns: 0 on Success. Errno otherwise
+ */
static int parse_options(struct super_block *sb, char *options)
{
substring_t args[MAX_OPT_ARGS];
@@ -351,6 +391,22 @@ static struct inode *erofs_init_managed_cache(struct
super_block *sb)
#endif
+/**
+ * erofs_read_super(): Helper function to erofs_fill_super()
+ *
+ * @sb: VFS superblock structure
+ * @dev_name: Name of device where erofs is mounted
+ * @data: Additional mount options
+ * @silent: if TRUE print message on error.
+ * Silent/quite otherwise
+ *
+ * Helper function to actual callback function erofs_fill_super
+ * This function sets the blocksize. Reads the superblock into
+ * buffer. Parses and sets mount options. Populates root inode
+ * and creates root directory.
+ *
+ * Returns: 0 on Success. Errno otherwise
+ */
static int erofs_read_super(struct super_block *sb,
const char *dev_name, void *data, int silent)
{
@@ -472,8 +528,12 @@ static int erofs_read_super(struct super_block *sb,
return err;
}
-/*
- * could be triggered after deactivate_locked_super()
+/**
+ * erofs_put_super(): Free superblock structure
+ *
+ * @sb: VFS superblock structure
+ *
+ * Could be triggered after deactivate_locked_super()
* is called, thus including umount and failed to initialize.
*/
static void erofs_put_super(struct super_block *sb)
@@ -513,7 +573,20 @@ struct erofs_mount_private {
char *options;
};
-/* support mount_bdev() with options */
+/**
+ * erofs_fill_super(): Fill erofs superblock
+ *
+ * @sb: VFS superblock structure
+ * @_priv: Additional Mount options
+ * @silent: if TRUE print message on error.
+ * Silent/quite otherwise
+ *
+ * This function fills erofs superblock information into
+ * the VFS superblock stucture. Additionally it supports
+ * mount_bdev() with options
+ *
+ * Returns: 0 on Success
+ */
static int erofs_fill_super(struct super_block *sb,
void *_priv, int silent)
{
@@ -523,6 +596,17 @@ static int erofs_fill_super(struct super_block *sb,
priv->options, silent);
}
+/**
+ * erofs_mount(): Function called when erofs is mounted
+ *
+ * @fs_type: Describes the erofs filesystem
+ * @flags: Mount flags/options
+ * @dev_name: Name of device where erofs is mounted
+ * @data: Mount options
+ *
+ * Returns: Pointer to VFS dentry structure.
+ * The root dentry.
+ */
static struct dentry *erofs_mount(
struct file_system_type *fs_type, int flags,
const char *dev_name, void *data)
@@ -532,10 +616,21 @@ static struct dentry *erofs_mount(
.options = data
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, Mar 12, 2019 at 7:43 PM Tim Murray wrote: > > On Tue, Mar 12, 2019 at 10:45 AM Sultan Alsawaf > wrote: > > > > On Tue, Mar 12, 2019 at 10:17:43AM -0700, Tim Murray wrote: > > > Knowing whether a SIGKILL'd process has finished reclaiming is as far > > > as I know not possible without something like procfds. That's where > > > the 100ms timeout in lmkd comes in. lowmemorykiller and lmkd both > > > attempt to wait up to 100ms for reclaim to finish by checking for the > > > continued existence of the thread that received the SIGKILL, but this > > > really means that they wait up to 100ms for the _thread_ to finish, > > > which doesn't tell you anything about the memory used by that process. > > > If those threads terminate early and lowmemorykiller/lmkd get a signal > > > to kill again, then there may be two processes competing for CPU time > > > to reclaim memory. That doesn't reclaim any faster and may be an > > > unnecessary kill. > > > ... > > > - offer a way to wait for process termination so lmkd can tell when > > > reclaim has finished and know when killing another process is > > > appropriate > > > > Should be pretty easy with something like this: > > Yeah, that's in the spirit of what I was suggesting, but there are lot > of edge cases around how to get that data out efficiently and PID > reuse (it's a real issue--often the Android apps that are causing > memory pressure are also constantly creating/destroying threads). > > I believe procfds or a similar mechanism will be a good solution to this. Fwiw, I am working on this and have send a PR for inclusion in 5.1: https://lore.kernel.org/lkml/20190312135245.27591-1-christ...@brauner.io/ There's also a tree to track this work. Christian ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, Mar 12, 2019 at 10:17:43AM -0700, Tim Murray wrote:
> Knowing whether a SIGKILL'd process has finished reclaiming is as far
> as I know not possible without something like procfds. That's where
> the 100ms timeout in lmkd comes in. lowmemorykiller and lmkd both
> attempt to wait up to 100ms for reclaim to finish by checking for the
> continued existence of the thread that received the SIGKILL, but this
> really means that they wait up to 100ms for the _thread_ to finish,
> which doesn't tell you anything about the memory used by that process.
> If those threads terminate early and lowmemorykiller/lmkd get a signal
> to kill again, then there may be two processes competing for CPU time
> to reclaim memory. That doesn't reclaim any faster and may be an
> unnecessary kill.
> ...
> - offer a way to wait for process termination so lmkd can tell when
> reclaim has finished and know when killing another process is
> appropriate
Should be pretty easy with something like this:
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 1549584a1..6ac478af2 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1199,6 +1199,7 @@ struct task_struct {
unsigned long lowest_stack;
unsigned long prev_lowest_stack;
#endif
+ ktime_t sigkill_time;
/*
* New fields for task_struct should be added above here, so that
diff --git a/kernel/fork.c b/kernel/fork.c
index 9dcd18aa2..0ae182777 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -435,6 +435,8 @@ void put_task_stack(struct task_struct *tsk)
void free_task(struct task_struct *tsk)
{
+ ktime_t sigkill_time = tsk->sigkill_time;
+ pid_t pid = tsk->pid;
#ifndef CONFIG_THREAD_INFO_IN_TASK
/*
* The task is finally done with both the stack and thread_info,
@@ -455,6 +457,9 @@ void free_task(struct task_struct *tsk)
if (tsk->flags & PF_KTHREAD)
free_kthread_struct(tsk);
free_task_struct(tsk);
+ if (sigkill_time)
+ printk("%d killed after %lld us\n", pid,
+ ktime_us_delta(ktime_get(), sigkill_time));
}
EXPORT_SYMBOL(free_task);
@@ -1881,6 +1886,7 @@ static __latent_entropy struct task_struct *copy_process(
p->sequential_io= 0;
p->sequential_io_avg= 0;
#endif
+ p->sigkill_time = 0;
/* Perform scheduler related setup. Assign this task to a CPU. */
retval = sched_fork(clone_flags, p);
diff --git a/kernel/signal.c b/kernel/signal.c
index 5d53183e2..1142c8811 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -1168,6 +1168,8 @@ static int __send_signal(int sig, struct kernel_siginfo
*info, struct task_struc
}
out_set:
+ if (sig == SIGKILL)
+ t->sigkill_time = ktime_get();
signalfd_notify(t, sig);
sigaddset(>signal, sig);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue 12-03-19 09:37:41, Sultan Alsawaf wrote: > I have not had a chance to look at PSI yet, but > unless a PSI-enabled solution allows allocations to reach the same point as > when > the OOM killer is invoked (which is contradictory to what it sets out to do), > then it cannot take advantage of all of the alternative memory-reclaim means > employed in the slowpath, and will result in killing a process before it is > _really_ necessary. One more note. The above is true, but you can also hit one of the thrashing reclaim behaviors and reclaim last few pages again and again with the whole system really sluggish. That is what PSI is trying to help with. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue 12-03-19 09:37:41, Sultan Alsawaf wrote: > On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > > The only way to control the OOM behavior pro-actively is to throttle > > allocation speed. We have memcg high limit for that purpose. Along with > > PSI, I can imagine a reasonably working user space early oom > > notifications and reasonable acting upon that. > > The issue with pro-active memory management that prompted me to create this > was > poor memory utilization. All of the alternative means of reclaiming pages in > the > page allocator's slow path turn out to be very useful for maximizing memory > utilization, which is something that we would have to forgo by relying on a > purely pro-active solution. I have not had a chance to look at PSI yet, but > unless a PSI-enabled solution allows allocations to reach the same point as > when > the OOM killer is invoked (which is contradictory to what it sets out to do), > then it cannot take advantage of all of the alternative memory-reclaim means > employed in the slowpath, and will result in killing a process before it is > _really_ necessary. If you really want to reach the real OOM situation then you can very well rely on the in-kernel OOM killer. The only reason you want a customized oom killer is the tasks clasification. And that is a different story. User space hints on the victim selection has been a topic for quite while. It never get to any conclusion as interested parties have always lost an interest because it got hairy quickly. > > If you design is relies on the speed of killing then it is fundamentally > > flawed AFAICT. You cannot assume anything about how quickly a task dies. > > It might be blocked in an uninterruptible sleep or performin an > > operation which takes some time. Sure, oom_reaper might help here but > > still. > > In theory we could instantly zap any process that is not trapped in the kernel > at the time that the OOM killer is invoked without any consequences though, > no? No, this is not so simple. Have a look at the oom_reaper and hops it has to go through. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > The only way to control the OOM behavior pro-actively is to throttle > allocation speed. We have memcg high limit for that purpose. Along with > PSI, I can imagine a reasonably working user space early oom > notifications and reasonable acting upon that. The issue with pro-active memory management that prompted me to create this was poor memory utilization. All of the alternative means of reclaiming pages in the page allocator's slow path turn out to be very useful for maximizing memory utilization, which is something that we would have to forgo by relying on a purely pro-active solution. I have not had a chance to look at PSI yet, but unless a PSI-enabled solution allows allocations to reach the same point as when the OOM killer is invoked (which is contradictory to what it sets out to do), then it cannot take advantage of all of the alternative memory-reclaim means employed in the slowpath, and will result in killing a process before it is _really_ necessary. > If you design is relies on the speed of killing then it is fundamentally > flawed AFAICT. You cannot assume anything about how quickly a task dies. > It might be blocked in an uninterruptible sleep or performin an > operation which takes some time. Sure, oom_reaper might help here but > still. In theory we could instantly zap any process that is not trapped in the kernel at the time that the OOM killer is invoked without any consequences though, no? Thanks, Sultan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue 12-03-19 16:33:15, Michal Hocko wrote: > On Tue 12-03-19 08:25:41, Matthew Wilcox wrote: > > On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > > > On Mon 11-03-19 15:15:35, Suren Baghdasaryan wrote: > > > > Yeah, killing speed is a well-known problem which we are considering > > > > in LMKD. For example the recent LMKD change to assign process being > > > > killed to a cpuset cgroup containing big cores cuts the kill time > > > > considerably. This is not ideal and we are thinking about better ways > > > > to expedite the cleanup process. > > > > > > If you design is relies on the speed of killing then it is fundamentally > > > flawed AFAICT. You cannot assume anything about how quickly a task dies. > > > It might be blocked in an uninterruptible sleep or performin an > > > operation which takes some time. Sure, oom_reaper might help here but > > > still. > > > > Many UNINTERRUPTIBLE sleeps can be converted to KILLABLE sleeps. It just > > needs someone to do the work. > > They can and should as much as possible. No question about that. But not > all of them can and that is why nobody should be relying on that. That > is the whole point of having the oom_reaper and async oom victim tear > down. Let me clarify a bit. LMK obviously doesn't need any guarantee like the core oom killer because it is more of a pro-active measure than the last resort. I merely wanted to say that relying on a design which assumes anything about time victim needs to exit is flawed and it will fail under different workloads. On the other hand this might work good enough on very specific workloads to be usable. I am not questioning that. The point is that this is not generic enough to be accepted to the upstream kernel. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 06/12] media: dt-bindings: add bindings for i.MX7 media driver
Hi Laurent,
On Tue 12 Mar 2019 at 15:10, Laurent Pinchart wrote:
Hi Rui,
On Tue, Mar 12, 2019 at 02:07:02PM +, Rui Miguel Silva
wrote:
On Sun 10 Mar 2019 at 21:48, Laurent Pinchart wrote:
> On Fri, May 18, 2018 at 09:27:58AM +0100, Rui Miguel Silva
> wrote:
>> On Fri 18 May 2018 at 06:58, Sakari Ailus wrote:
>>> On Thu, May 17, 2018 at 01:50:27PM +0100, Rui Miguel Silva
>>> wrote:
Add bindings documentation for i.MX7 media drivers.
Signed-off-by: Rui Miguel Silva
---
.../devicetree/bindings/media/imx7.txt| 145
++
1 file changed, 145 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/imx7.txt
1
diff --git
a/Documentation/devicetree/bindings/media/imx7.txt
b/Documentation/devicetree/bindings/media/imx7.txt
new file mode 100644
index ..161cff8e6442
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx7.txt
@@ -0,0 +1,145 @@
+Freescale i.MX7 Media Video Device
+==
+
+Video Media Controller node
+---
>>>
>>> Note that DT bindings document the hardware, they are as
>>> such
>>> not Linux dependent.
>>
>> This was removed in this series, however I removed it in the
>> wrong
>> patch, If you see patch 11/12 you will see this being
>> removed. I
>> will fix this in v5. Thanks for notice it.
>>
+
+This is the media controller node for video capture
support. It is a
+virtual device that lists the camera serial interface
nodes that the
+media device will control.
>>>
>>> Ditto.
>>>
+
+Required properties:
+- compatible : "fsl,imx7-capture-subsystem";
+- ports : Should contain a list of phandles pointing
to camera
+ sensor interface port of CSI
+
+example:
+
+capture-subsystem {
>>>
>>> What's the purpose of this node, if you only refer to
>>> another
>>> device? This one rather does not look like a real device at
>>> all.
>>>
+ compatible = "fsl,imx7-capture-subsystem";
+ ports = <>;
+};
+
+
+mipi_csi2 node
+--
+
+This is the device node for the MIPI CSI-2 receiver core
in i.MX7 SoC. It is
+compatible with previous version of Samsung D-phy.
+
+Required properties:
+
+- compatible: "fsl,imx7-mipi-csi2";
+- reg : base address and length of the register
set for the device;
+- interrupts: should contain MIPI CSIS interrupt;
+- clocks: list of clock specifiers, see
+
Documentation/devicetree/bindings/clock/clock-bindings.txt
for details;
+- clock-names : must contain "pclk", "wrap" and "phy"
entries, matching
+ entries in the clock property;
+- power-domains : a phandle to the power domain, see
+
Documentation/devicetree/bindings/power/power_domain.txt
for details.
+- reset-names : should include following entry "mrst";
+- resets: a list of phandle, should contain reset
entry of
+ reset-names;
+- phy-supply: from the generic phy bindings, a
phandle to a regulator that
+provides power to MIPI CSIS core;
+- bus-width : maximum number of data lanes supported
(SoC specific);
+
+Optional properties:
+
+- clock-frequency : The IP's main (system bus) clock
frequency in Hz, default
+ value when this property is not
specified is 166 MHz;
+
+port node
+-
+
+- reg : (required) can take the values 0 or 1,
where 0 is the
+ related sink port and port 1 should
be the source one;
+
+endpoint node
+-
+
+- data-lanes: (required) an array specifying active
physical MIPI-CSI2
+ data input lanes and their mapping to
logical lanes; the
+ array's content is unused, only its
length is meaningful;
+
+- fsl,csis-hs-settle : (optional) differential receiver
(HS-RX) settle time;
>>>
>>> Could you calculate this, as other drivers do? It probably
>>> changes> depending on the device runtime configuration.
>>
>> The only reference to possible values to this parameter is
>> given by
>> table in [0], can you point me out the formula for imx7 in
>> the
>> documentation?
>>
>> [0] https://community.nxp.com/thread/463777
>
> Can't you use the values from that table ? :-) You can get
> the
> link speed by querying the connected subdev and reading its
> V4L2_CID_PIXEL_RATE control.
Yeah, I good point to add support for others subdev's. I will
try
to add your comments in a follow up series.
Just for my information (no commitment), do you know
Re: [PATCH v14 08/13] ARM: dts: imx7: Add video mux, csi and mipi_csi and connections
Hi Laurent,
On Tue 12 Mar 2019 at 14:10, Laurent Pinchart wrote:
Hi Rui,
On Tue, Mar 12, 2019 at 02:05:24PM +, Rui Miguel Silva
wrote:
On Sun 10 Mar 2019 at 21:41, Laurent Pinchart wrote:
> Hi Rui,
>
> Thank you for the patch.
Where have you been for the latest 14 versions? :)
Elsewhere I suppose :-)
eheh.
This is already merged, but... follow up patches can address
your
issues bellow.
I saw the driver and DT bindings patches merged in the media
tree for
v5.2, where have the DT patches been merged ?
Good question, now that you talk I do not think they were merged.
> On Wed, Feb 06, 2019 at 03:13:23PM +, Rui Miguel Silva
> wrote:
>> This patch adds the device tree nodes for csi, video
>> multiplexer and mipi-csi besides the graph connecting the
>> necessary
>> endpoints to make the media capture entities to work in imx7
>> Warp
>> board.
>>
>> Signed-off-by: Rui Miguel Silva
>> ---
>> arch/arm/boot/dts/imx7s-warp.dts | 51
>>
>> arch/arm/boot/dts/imx7s.dtsi | 27 +
>
> I would have split this in two patches to make backporting
> easier, but it's not a big deal.
>
> Please see below for a few additional comments.
>
>> 2 files changed, 78 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx7s-warp.dts
>> b/arch/arm/boot/dts/imx7s-warp.dts
>> index 23431faecaf4..358bcae7ebaf 100644
>> --- a/arch/arm/boot/dts/imx7s-warp.dts
>> +++ b/arch/arm/boot/dts/imx7s-warp.dts
>> @@ -277,6 +277,57 @@
>>status = "okay";
>> };
>>
>> + {
>> + csi_mux {
>> + compatible = "video-mux";
>> + mux-controls = < 0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@1 {
>> + reg = <1>;
>> +
>> + csi_mux_from_mipi_vc0: endpoint {
>> +remote-endpoint =
>> <_vc0_to_csi_mux>;
>> + };
>> + };
>> +
>> + port@2 {
>> + reg = <2>;
>> +
>> + csi_mux_to_csi: endpoint {
>> +remote-endpoint =
>> <_from_csi_mux>;
>> + };
>> + };
>> + };
>> +};
>> +
>> + {
>> + status = "okay";
>> +
>> + port {
>> + csi_from_csi_mux: endpoint {
>> + remote-endpoint = <_mux_to_csi>;
>> + };
>> + };
>> +};
>
> Shouldn't these two nodes, as well as port@1 of the mipi_csi
> node, be moved to imx7d.dtsi ?
Yeah, I guess you are right here.
>
>> +
>> +_csi {
>> + clock-frequency = <16600>;
>> + status = "okay";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + fsl,csis-hs-settle = <3>;
>
> Shouldn't this be an endpoint property ? Different sensors
> connected
> through different endpoints could have different timing
> requirements.
Hum... I see you point, even tho the phy hs-settle is a common
control.
I suppose we don't need to care about DT backward compatibility
if we
make changes in the bindings for v5.2 ? Would you fix this, or
do you
want a patch ?
I will try to take a look at this until end of week.
---
Cheers,
Rui
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue 12-03-19 08:25:41, Matthew Wilcox wrote: > On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > > On Mon 11-03-19 15:15:35, Suren Baghdasaryan wrote: > > > Yeah, killing speed is a well-known problem which we are considering > > > in LMKD. For example the recent LMKD change to assign process being > > > killed to a cpuset cgroup containing big cores cuts the kill time > > > considerably. This is not ideal and we are thinking about better ways > > > to expedite the cleanup process. > > > > If you design is relies on the speed of killing then it is fundamentally > > flawed AFAICT. You cannot assume anything about how quickly a task dies. > > It might be blocked in an uninterruptible sleep or performin an > > operation which takes some time. Sure, oom_reaper might help here but > > still. > > Many UNINTERRUPTIBLE sleeps can be converted to KILLABLE sleeps. It just > needs someone to do the work. They can and should as much as possible. No question about that. But not all of them can and that is why nobody should be relying on that. That is the whole point of having the oom_reaper and async oom victim tear down. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Tue, Mar 12, 2019 at 09:05:32AM +0100, Michal Hocko wrote: > On Mon 11-03-19 15:15:35, Suren Baghdasaryan wrote: > > Yeah, killing speed is a well-known problem which we are considering > > in LMKD. For example the recent LMKD change to assign process being > > killed to a cpuset cgroup containing big cores cuts the kill time > > considerably. This is not ideal and we are thinking about better ways > > to expedite the cleanup process. > > If you design is relies on the speed of killing then it is fundamentally > flawed AFAICT. You cannot assume anything about how quickly a task dies. > It might be blocked in an uninterruptible sleep or performin an > operation which takes some time. Sure, oom_reaper might help here but > still. Many UNINTERRUPTIBLE sleeps can be converted to KILLABLE sleeps. It just needs someone to do the work. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] Staging: rtl8723bs: os_dep: Fix several coding style errors
No problem. In a previous patch I had one for each item, but I thought it could be packed in a single one - and avoid '[PATCH n/m]'. Thanks. On 3/12/19, Dan Carpenter wrote: > On Tue, Mar 12, 2019 at 11:39:13AM -0300, Guilherme T Maeoka wrote: >> From: Guilherme T Maeoka >> >> Fix coding style errors and warns complained by checkpatck.pl. To list: >> >> - remove braces for single statements blocks, >> - add space required around operators, >> - replace spaces with tabs to indent, >> - add blank line after declarations, >> - fix braces and 'else' poistions in selection statements. >> > > I'm sorry you're going to have to break this up into multiple patches. > Probably one for each item on your list. > > regards, > dan carpenter > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] Staging: rtl8723bs: os_dep: Fix several coding style errors
On Tue, Mar 12, 2019 at 11:39:13AM -0300, Guilherme T Maeoka wrote: > From: Guilherme T Maeoka > > Fix coding style errors and warns complained by checkpatck.pl. To list: > > - remove braces for single statements blocks, > - add space required around operators, > - replace spaces with tabs to indent, > - add blank line after declarations, > - fix braces and 'else' poistions in selection statements. > I'm sorry you're going to have to break this up into multiple patches. Probably one for each item on your list. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 06/12] media: dt-bindings: add bindings for i.MX7 media driver
Hi Rui,
On Tue, Mar 12, 2019 at 02:07:02PM +, Rui Miguel Silva wrote:
> On Sun 10 Mar 2019 at 21:48, Laurent Pinchart wrote:
> > On Fri, May 18, 2018 at 09:27:58AM +0100, Rui Miguel Silva wrote:
> >> On Fri 18 May 2018 at 06:58, Sakari Ailus wrote:
> >>> On Thu, May 17, 2018 at 01:50:27PM +0100, Rui Miguel Silva wrote:
> Add bindings documentation for i.MX7 media drivers.
>
> Signed-off-by: Rui Miguel Silva
> ---
> .../devicetree/bindings/media/imx7.txt| 145 ++
> 1 file changed, 145 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/imx7.txt
> 1
> diff --git
> a/Documentation/devicetree/bindings/media/imx7.txt
> b/Documentation/devicetree/bindings/media/imx7.txt
> new file mode 100644
> index ..161cff8e6442
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx7.txt
> @@ -0,0 +1,145 @@
> +Freescale i.MX7 Media Video Device
> +==
> +
> +Video Media Controller node
> +---
> >>>
> >>> Note that DT bindings document the hardware, they are as such
> >>> not Linux dependent.
> >>
> >> This was removed in this series, however I removed it in the wrong
> >> patch, If you see patch 11/12 you will see this being removed. I
> >> will fix this in v5. Thanks for notice it.
> >>
> +
> +This is the media controller node for video capture support. It is a
> +virtual device that lists the camera serial interface nodes that the
> +media device will control.
> >>>
> >>> Ditto.
> >>>
> +
> +Required properties:
> +- compatible : "fsl,imx7-capture-subsystem";
> +- ports : Should contain a list of phandles pointing to camera
> +sensor interface port of CSI
> +
> +example:
> +
> +capture-subsystem {
> >>>
> >>> What's the purpose of this node, if you only refer to another
> >>> device? This one rather does not look like a real device at
> >>> all.
> >>>
> +compatible = "fsl,imx7-capture-subsystem";
> +ports = <>;
> +};
> +
> +
> +mipi_csi2 node
> +--
> +
> +This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC.
> It is
> +compatible with previous version of Samsung D-phy.
> +
> +Required properties:
> +
> +- compatible: "fsl,imx7-mipi-csi2";
> +- reg : base address and length of the register set for the
> device;
> +- interrupts: should contain MIPI CSIS interrupt;
> +- clocks: list of clock specifiers, see
> +
> Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
> +- clock-names : must contain "pclk", "wrap" and "phy" entries,
> matching
> + entries in the clock property;
> +- power-domains : a phandle to the power domain, see
> +
> Documentation/devicetree/bindings/power/power_domain.txt for details.
> +- reset-names : should include following entry "mrst";
> +- resets: a list of phandle, should contain reset entry of
> + reset-names;
> +- phy-supply: from the generic phy bindings, a phandle to a
> regulator that
> + provides power to MIPI CSIS core;
> +- bus-width : maximum number of data lanes supported (SoC specific);
> +
> +Optional properties:
> +
> +- clock-frequency : The IP's main (system bus) clock frequency in Hz,
> default
> +value when this property is not specified is 166
> MHz;
> +
> +port node
> +-
> +
> +- reg : (required) can take the values 0 or 1, where 0 is
> the
> + related sink port and port 1 should be the source
> one;
> +
> +endpoint node
> +-
> +
> +- data-lanes: (required) an array specifying active physical
> MIPI-CSI2
> +data input lanes and their mapping to logical
> lanes; the
> +array's content is unused, only its length is
> meaningful;
> +
> +- fsl,csis-hs-settle : (optional) differential receiver (HS-RX) settle
> time;
> >>>
> >>> Could you calculate this, as other drivers do? It probably
> >>> changes> depending on the device runtime configuration.
> >>
> >> The only reference to possible values to this parameter is given by
> >> table in [0], can you point me out the formula for imx7 in the
> >> documentation?
> >>
> >> [0] https://community.nxp.com/thread/463777
> >
> > Can't you use the values from that table ? :-) You can get the
> > link speed by querying the connected subdev and reading its
> > V4L2_CID_PIXEL_RATE control.
>
> Yeah, I good point to
[PATCH 2/2] Staging: rtl8723bs: os_dep: Invert if selection statement
From: Guilherme T Maeoka
Change 'if (a)' to 'if (!a)' and return. Otherwise, continue with
the previouly wrapped block of control. This reduces the indentation
level by 2 and 1.
I'm not if this commit contributes to the coding style.
Signed-off-by: Guilherme T Maeoka
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 73 +++-
1 file changed, 40 insertions(+), 33 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index 86f1e090436e..54425ad28bfd 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -103,23 +103,27 @@ static void sdio_free_irq(struct dvobj_priv *dvobj)
struct sdio_func *func;
int err;
- if (dvobj->irq_alloc) {
- psdio_data = >intf_data;
- func = psdio_data->func;
-
- if (func) {
- sdio_claim_host(func);
- err = sdio_release_irq(func);
- if (err) {
- dvobj->drv_dbg.dbg_sdio_free_irq_error_cnt++;
- DBG_871X_LEVEL(_drv_err_, "%s: sdio_release_irq
FAIL(%d)!\n", __func__, err);
- } else {
- dvobj->drv_dbg.dbg_sdio_free_irq_cnt++;
- }
- sdio_release_host(func);
- }
- dvobj->irq_alloc = 0;
+ if (!dvobj->irq_alloc)
+ return;
+
+ psdio_data = >intf_data;
+ func = psdio_data->func;
+ dvobj->irq_alloc = 0;
+
+ if (!func)
+ return;
+
+ sdio_claim_host(func);
+ err = sdio_release_irq(func);
+ if (err) {
+ dvobj->drv_dbg.dbg_sdio_free_irq_error_cnt++;
+ DBG_871X_LEVEL(_drv_err_, "%s: sdio_release_irq FAIL(%d)!\n",
+ __func__, err);
+ } else {
+ dvobj->drv_dbg.dbg_sdio_free_irq_cnt++;
}
+
+ sdio_release_host(func);
}
#ifdef CONFIG_GPIO_WAKEUP
@@ -219,26 +223,29 @@ static void sdio_deinit(struct dvobj_priv *dvobj)
func = dvobj->intf_data.func;
- if (func) {
- sdio_claim_host(func);
- err = sdio_disable_func(func);
- if (err) {
- dvobj->drv_dbg.dbg_sdio_deinit_error_cnt++;
- DBG_8192C(KERN_ERR "%s: sdio_disable_func(%d)\n",
__func__, err);
- }
+ if (!func)
+ return;
- if (dvobj->irq_alloc) {
- err = sdio_release_irq(func);
- if (err) {
- dvobj->drv_dbg.dbg_sdio_free_irq_error_cnt++;
- DBG_8192C(KERN_ERR "%s:
sdio_release_irq(%d)\n", __func__, err);
- } else {
- dvobj->drv_dbg.dbg_sdio_free_irq_cnt++;
- }
- }
+ sdio_claim_host(func);
+ err = sdio_disable_func(func);
+ if (err) {
+ dvobj->drv_dbg.dbg_sdio_deinit_error_cnt++;
+ DBG_8192C(KERN_ERR "%s: sdio_disable_func(%d)\n",
+ __func__, err);
+ }
- sdio_release_host(func);
+ if (dvobj->irq_alloc) {
+ err = sdio_release_irq(func);
+ if (err) {
+ dvobj->drv_dbg.dbg_sdio_free_irq_error_cnt++;
+ DBG_8192C(KERN_ERR "%s: sdio_release_irq(%d)\n",
+ __func__, err);
+ } else {
+ dvobj->drv_dbg.dbg_sdio_free_irq_cnt++;
+ }
}
+
+ sdio_release_host(func);
}
static struct dvobj_priv *sdio_dvobj_init(struct sdio_func *func)
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] Staging: rtl8723bs: os_dep: Fix several coding style errors
From: Guilherme T Maeoka
Fix coding style errors and warns complained by checkpatck.pl. To list:
- remove braces for single statements blocks,
- add space required around operators,
- replace spaces with tabs to indent,
- add blank line after declarations,
- fix braces and 'else' poistions in selection statements.
Signed-off-by: Guilherme T Maeoka
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 112 +--
1 file changed, 50 insertions(+), 62 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index 6d02904de63f..86f1e090436e 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -14,14 +14,14 @@
#define dev_to_sdio_func(d) container_of(d, struct sdio_func, dev)
#endif
-static const struct sdio_device_id sdio_ids[] =
-{
+static const struct sdio_device_id sdio_ids[] = {
{ SDIO_DEVICE(0x024c, 0x0523), },
{ SDIO_DEVICE(0x024c, 0x0623), },
{ SDIO_DEVICE(0x024c, 0x0626), },
{ SDIO_DEVICE(0x024c, 0xb723), },
{ /* end: all zeroes */ },
};
+
static const struct acpi_device_id acpi_ids[] = {
{"OBDA8723", 0x},
{}
@@ -84,46 +84,42 @@ static int sdio_alloc_irq(struct dvobj_priv *dvobj)
sdio_claim_host(func);
err = sdio_claim_irq(func, _sync_int_hdl);
- if (err)
- {
+ if (err) {
dvobj->drv_dbg.dbg_sdio_alloc_irq_error_cnt++;
printk(KERN_CRIT "%s: sdio_claim_irq FAIL(%d)!\n", __func__,
err);
- }
- else
- {
+ } else {
dvobj->drv_dbg.dbg_sdio_alloc_irq_cnt++;
dvobj->irq_alloc = 1;
}
sdio_release_host(func);
- return err?_FAIL:_SUCCESS;
+ return err ? _FAIL : _SUCCESS;
}
static void sdio_free_irq(struct dvobj_priv *dvobj)
{
-PSDIO_DATA psdio_data;
-struct sdio_func *func;
-int err;
-
-if (dvobj->irq_alloc) {
-psdio_data = >intf_data;
-func = psdio_data->func;
-
-if (func) {
-sdio_claim_host(func);
-err = sdio_release_irq(func);
-if (err)
-{
+ PSDIO_DATA psdio_data;
+ struct sdio_func *func;
+ int err;
+
+ if (dvobj->irq_alloc) {
+ psdio_data = >intf_data;
+ func = psdio_data->func;
+
+ if (func) {
+ sdio_claim_host(func);
+ err = sdio_release_irq(func);
+ if (err) {
dvobj->drv_dbg.dbg_sdio_free_irq_error_cnt++;
- DBG_871X_LEVEL(_drv_err_,"%s: sdio_release_irq
FAIL(%d)!\n", __func__, err);
-}
-else
- dvobj->drv_dbg.dbg_sdio_free_irq_cnt++;
-sdio_release_host(func);
-}
-dvobj->irq_alloc = 0;
-}
+ DBG_871X_LEVEL(_drv_err_, "%s: sdio_release_irq
FAIL(%d)!\n", __func__, err);
+ } else {
+ dvobj->drv_dbg.dbg_sdio_free_irq_cnt++;
+ }
+ sdio_release_host(func);
+ }
+ dvobj->irq_alloc = 0;
+ }
}
#ifdef CONFIG_GPIO_WAKEUP
@@ -131,16 +127,18 @@ extern unsigned int oob_irq;
static irqreturn_t gpio_hostwakeup_irq_thread(int irq, void *data)
{
struct adapter *padapter = data;
+
DBG_871X_LEVEL(_drv_always_, "gpio_hostwakeup_irq_thread\n");
/* Disable interrupt before calling handler */
/* disable_irq_nosync(oob_irq); */
- rtw_lock_suspend_timeout(HZ/2);
+ rtw_lock_suspend_timeout(HZ / 2);
return IRQ_HANDLED;
}
static u8 gpio_hostwakeup_alloc_irq(struct adapter *padapter)
{
int err;
+
if (oob_irq == 0) {
DBG_871X("oob_irq ZERO!\n");
return _FAIL;
@@ -150,9 +148,9 @@ static u8 gpio_hostwakeup_alloc_irq(struct adapter
*padapter)
/* and failing can prevent can not sleep issue if */
/* wifi gpio12 pin is not linked with CPU */
err = request_threaded_irq(oob_irq, gpio_hostwakeup_irq_thread, NULL,
- /* IRQF_TRIGGER_LOW | IRQF_ONESHOT, */
- IRQF_TRIGGER_FALLING,
- "rtw_wifi_gpio_wakeup", padapter);
+ /* IRQF_TRIGGER_LOW | IRQF_ONESHOT, */
+ IRQF_TRIGGER_FALLING,
+ "rtw_wifi_gpio_wakeup", padapter);
if (err < 0) {
DBG_871X("Oops: can't allocate gpio irq %d err:%d\n", oob_irq,
err);
return false;
@@ -224,26 +222,25 @@ static void sdio_deinit(struct dvobj_priv *dvobj)
if (func) {
sdio_claim_host(func);
err = sdio_disable_func(func);
- if (err)
[PATCH] staging: rtl8192u: Add required spaces before open parenthesis
Fix error reported by checkpatch.pl
Signed-off-by: Sidong Yang
---
drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c | 22 +++
.../staging/rtl8192u/ieee80211/rtl819x_TSProc.c| 68 +++---
2 files changed, 45 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
index 024fa2702546..ea9c69eeceae 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
@@ -318,17 +318,17 @@ static void ieee80211_tx_query_agg_cap(struct
ieee80211_device *ieee,
return;
//check packet and mode later
#ifdef TO_DO_LIST
- if(pTcb->PacketLength >= 4096)
+ if (pTcb->PacketLength >= 4096)
return;
// For RTL819X, if pairwisekey = wep/tkip, we don't aggrregation.
- if(!Adapter->HalFunc.GetNmodeSupportBySecCfgHandler(Adapter))
+ if (!Adapter->HalFunc.GetNmodeSupportBySecCfgHandler(Adapter))
return;
#endif
- if(!ieee->GetNmodeSupportBySecCfg(ieee->dev))
+ if (!ieee->GetNmodeSupportBySecCfg(ieee->dev))
{
return;
}
- if(pHTInfo->bCurrentAMPDUEnable)
+ if (pHTInfo->bCurrentAMPDUEnable)
{
if (!GetTs(ieee, (struct ts_common_info **)(),
hdr->addr1, skb->priority, TX_DIR, true))
{
@@ -398,18 +398,18 @@ ieee80211_query_HTCapShortGI(struct ieee80211_device
*ieee, struct cb_desc *tcb_
tcb_desc->bUseShortGI = false;
- if(!pHTInfo->bCurrentHTSupport||!pHTInfo->bEnableHT)
+ if (!pHTInfo->bCurrentHTSupport||!pHTInfo->bEnableHT)
return;
- if(pHTInfo->bForcedShortGI)
+ if (pHTInfo->bForcedShortGI)
{
tcb_desc->bUseShortGI = true;
return;
}
- if((pHTInfo->bCurBW40MHz==true) && pHTInfo->bCurShortGI40MHz)
+ if ((pHTInfo->bCurBW40MHz==true) && pHTInfo->bCurShortGI40MHz)
tcb_desc->bUseShortGI = true;
- else if((pHTInfo->bCurBW40MHz==false) && pHTInfo->bCurShortGI20MHz)
+ else if ((pHTInfo->bCurBW40MHz==false) && pHTInfo->bCurShortGI20MHz)
tcb_desc->bUseShortGI = true;
}
@@ -420,13 +420,13 @@ static void ieee80211_query_BandwidthMode(struct
ieee80211_device *ieee,
tcb_desc->bPacketBW = false;
- if(!pHTInfo->bCurrentHTSupport||!pHTInfo->bEnableHT)
+ if (!pHTInfo->bCurrentHTSupport||!pHTInfo->bEnableHT)
return;
- if(tcb_desc->bMulticast || tcb_desc->bBroadcast)
+ if (tcb_desc->bMulticast || tcb_desc->bBroadcast)
return;
- if((tcb_desc->data_rate & 0x80)==0) // If using legacy rate, it shall
use 20MHz channel.
+ if ((tcb_desc->data_rate & 0x80)==0) // If using legacy rate, it shall
use 20MHz channel.
return;
//BandWidthAutoSwitch is for auto switch to 20 or 40 in long distance
if(pHTInfo->bCurBW40MHz && pHTInfo->bCurTxBW40MHz &&
!ieee->bandwidth_auto_switch.bforced_tx20Mhz)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
index 0368e5e3e95d..4bb6c32b9bf0 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c
@@ -37,18 +37,18 @@ static void RxPktPendingTimeout(struct timer_list *t)
spin_lock_irqsave(&(ieee->reorder_spinlock), flags);
IEEE80211_DEBUG(IEEE80211_DL_REORDER, "==>%s()\n",
__func__);
- if(pRxTs->rx_timeout_indicate_seq != 0x) {
+ if (pRxTs->rx_timeout_indicate_seq != 0x) {
// Indicate the pending packets sequentially according to
SeqNum until meet the gap.
- while(!list_empty(>rx_pending_pkt_list)) {
+ while (!list_empty(>rx_pending_pkt_list)) {
pReorderEntry =
list_entry(pRxTs->rx_pending_pkt_list.prev, struct rx_reorder_entry, List);
- if(index == 0)
+ if (index == 0)
pRxTs->rx_indicate_seq = pReorderEntry->SeqNum;
- if( SN_LESS(pReorderEntry->SeqNum,
pRxTs->rx_indicate_seq) ||
- SN_EQUAL(pReorderEntry->SeqNum,
pRxTs->rx_indicate_seq) ) {
+ if (SN_LESS(pReorderEntry->SeqNum,
pRxTs->rx_indicate_seq) ||
+ SN_EQUAL(pReorderEntry->SeqNum,
pRxTs->rx_indicate_seq)) {
list_del_init(>List);
- if(SN_EQUAL(pReorderEntry->SeqNum,
pRxTs->rx_indicate_seq))
+ if (SN_EQUAL(pReorderEntry->SeqNum,
pRxTs->rx_indicate_seq))
pRxTs->rx_indicate_seq =
(pRxTs->rx_indicate_seq + 1) % 4096;
Re: [PATCH v14 08/13] ARM: dts: imx7: Add video mux, csi and mipi_csi and connections
Hi Rui,
On Tue, Mar 12, 2019 at 02:05:24PM +, Rui Miguel Silva wrote:
> On Sun 10 Mar 2019 at 21:41, Laurent Pinchart wrote:
> > Hi Rui,
> >
> > Thank you for the patch.
>
> Where have you been for the latest 14 versions? :)
Elsewhere I suppose :-)
> This is already merged, but... follow up patches can address your
> issues bellow.
I saw the driver and DT bindings patches merged in the media tree for
v5.2, where have the DT patches been merged ?
> > On Wed, Feb 06, 2019 at 03:13:23PM +, Rui Miguel Silva
> > wrote:
> >> This patch adds the device tree nodes for csi, video
> >> multiplexer and mipi-csi besides the graph connecting the necessary
> >> endpoints to make the media capture entities to work in imx7 Warp
> >> board.
> >>
> >> Signed-off-by: Rui Miguel Silva
> >> ---
> >> arch/arm/boot/dts/imx7s-warp.dts | 51
> >> arch/arm/boot/dts/imx7s.dtsi | 27 +
> >
> > I would have split this in two patches to make backporting
> > easier, but it's not a big deal.
> >
> > Please see below for a few additional comments.
> >
> >> 2 files changed, 78 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/imx7s-warp.dts
> >> b/arch/arm/boot/dts/imx7s-warp.dts
> >> index 23431faecaf4..358bcae7ebaf 100644
> >> --- a/arch/arm/boot/dts/imx7s-warp.dts
> >> +++ b/arch/arm/boot/dts/imx7s-warp.dts
> >> @@ -277,6 +277,57 @@
> >>status = "okay";
> >> };
> >>
> >> + {
> >> + csi_mux {
> >> + compatible = "video-mux";
> >> + mux-controls = < 0>;
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + port@1 {
> >> + reg = <1>;
> >> +
> >> + csi_mux_from_mipi_vc0: endpoint {
> >> + remote-endpoint =
> >> <_vc0_to_csi_mux>;
> >> + };
> >> + };
> >> +
> >> + port@2 {
> >> + reg = <2>;
> >> +
> >> + csi_mux_to_csi: endpoint {
> >> + remote-endpoint =
> >> <_from_csi_mux>;
> >> + };
> >> + };
> >> + };
> >> +};
> >> +
> >> + {
> >> + status = "okay";
> >> +
> >> + port {
> >> + csi_from_csi_mux: endpoint {
> >> + remote-endpoint = <_mux_to_csi>;
> >> + };
> >> + };
> >> +};
> >
> > Shouldn't these two nodes, as well as port@1 of the mipi_csi
> > node, be moved to imx7d.dtsi ?
>
> Yeah, I guess you are right here.
>
> >
> >> +
> >> +_csi {
> >> + clock-frequency = <16600>;
> >> + status = "okay";
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + fsl,csis-hs-settle = <3>;
> >
> > Shouldn't this be an endpoint property ? Different sensors connected
> > through different endpoints could have different timing
> > requirements.
>
> Hum... I see you point, even tho the phy hs-settle is a common
> control.
I suppose we don't need to care about DT backward compatibility if we
make changes in the bindings for v5.2 ? Would you fix this, or do you
want a patch ?
> >> +
> >> + port@1 {
> >> + reg = <1>;
> >> +
> >> + mipi_vc0_to_csi_mux: endpoint {
> >> + remote-endpoint = <_mux_from_mipi_vc0>;
> >> + };
> >> + };
> >> +};
> >> +
> >> {
> >>pinctrl-names = "default";
> >>pinctrl-0 = <_wdog>;
> >> diff --git a/arch/arm/boot/dts/imx7s.dtsi
> >> b/arch/arm/boot/dts/imx7s.dtsi
> >> index 792efcd2caa1..01962f85cab6 100644
> >> --- a/arch/arm/boot/dts/imx7s.dtsi
> >> +++ b/arch/arm/boot/dts/imx7s.dtsi
> >> @@ -8,6 +8,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include "imx7d-pinfunc.h"
> >>
> >> / {
> >> @@ -709,6 +710,17 @@
> >>status = "disabled";
> >>};
> >>
> >> + csi: csi@3071 {
> >> + compatible = "fsl,imx7-csi";
> >> + reg = <0x3071 0x1>;
> >> + interrupts = ;
> >> + clocks = < IMX7D_CLK_DUMMY>,
> >> + < IMX7D_CSI_MCLK_ROOT_CLK>,
> >> + < IMX7D_CLK_DUMMY>;
> >> + clock-names = "axi", "mclk", "dcic";
> >> + status = "disabled";
> >> + };
> >> +
> >>lcdif: lcdif@3073 {
> >>compatible = "fsl,imx7d-lcdif",
> >> "fsl,imx28-lcdif";
> >>reg = <0x3073 0x1>;
> >> @@ -718,6 +730,21 @@
> >>clock-names = "pix", "axi";
> >>status = "disabled";
> >>};
> >> +
> >> + mipi_csi: mipi-csi@3075 {
> >> + compatible = "fsl,imx7-mipi-csi2";
> >> + reg = <0x3075 0x1>;
> >> + interrupts = ;
> >> +
Re: [PATCH v4 06/12] media: dt-bindings: add bindings for i.MX7 media driver
Hi Laurent,
On Sun 10 Mar 2019 at 21:48, Laurent Pinchart wrote:
Hi Rui,
On Fri, May 18, 2018 at 09:27:58AM +0100, Rui Miguel Silva
wrote:
Hi Sakari,
Thanks for the review.
On Fri 18 May 2018 at 06:58, Sakari Ailus wrote:
> On Thu, May 17, 2018 at 01:50:27PM +0100, Rui Miguel Silva
> wrote:
>> Add bindings documentation for i.MX7 media drivers.
>>
>> Signed-off-by: Rui Miguel Silva
>> ---
>> .../devicetree/bindings/media/imx7.txt| 145
>> ++
>> 1 file changed, 145 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/media/imx7.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/media/imx7.txt
>> b/Documentation/devicetree/bindings/media/imx7.txt
>> new file mode 100644
>> index ..161cff8e6442
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/imx7.txt
>> @@ -0,0 +1,145 @@
>> +Freescale i.MX7 Media Video Device
>> +==
>> +
>> +Video Media Controller node
>> +---
>
> Note that DT bindings document the hardware, they are as such
> not Linux dependent.
This was removed in this series, however I removed it in the
wrong
patch, If you see patch 11/12 you will see this being removed.
I will
fix this in v5. Thanks for notice it.
>> +
>> +This is the media controller node for video capture
>> support.
>> It is a
>> +virtual device that lists the camera serial interface nodes
>> that the
>> +media device will control.
>
> Ditto.
>
>> +
>> +Required properties:
>> +- compatible : "fsl,imx7-capture-subsystem";
>> +- ports : Should contain a list of phandles pointing
>> to
>> camera
>> + sensor interface port of CSI
>> +
>> +example:
>> +
>> +capture-subsystem {
>
> What's the purpose of this node, if you only refer to another
> device? This one rather does not look like a real device at
> all.
>
>> + compatible = "fsl,imx7-capture-subsystem";
>> + ports = <>;
>> +};
>> +
>> +
>> +mipi_csi2 node
>> +--
>> +
>> +This is the device node for the MIPI CSI-2 receiver core in
>> i.MX7 SoC. It is
>> +compatible with previous version of Samsung D-phy.
>> +
>> +Required properties:
>> +
>> +- compatible: "fsl,imx7-mipi-csi2";
>> +- reg : base address and length of the register
>> set
>> for the device;
>> +- interrupts: should contain MIPI CSIS interrupt;
>> +- clocks: list of clock specifiers, see
>> +
>> Documentation/devicetree/bindings/clock/clock-bindings.txt
>> for
>> details;
>> +- clock-names : must contain "pclk", "wrap" and "phy"
>> entries, matching
>> + entries in the clock property;
>> +- power-domains : a phandle to the power domain, see
>> +
>> Documentation/devicetree/bindings/power/power_domain.txt for
>> details.
>> +- reset-names : should include following entry "mrst";
>> +- resets: a list of phandle, should contain reset
>> entry of
>> + reset-names;
>> +- phy-supply: from the generic phy bindings, a phandle
>> to
>> a regulator that
>> +provides power to MIPI CSIS core;
>> +- bus-width : maximum number of data lanes supported
>> (SoC
>> specific);
>> +
>> +Optional properties:
>> +
>> +- clock-frequency : The IP's main (system bus) clock
>> frequency
>> in Hz, default
>> + value when this property is not specified is
>> 166 MHz;
>> +
>> +port node
>> +-
>> +
>> +- reg : (required) can take the values 0 or 1,
>> where 0 is the
>> + related sink port and port 1 should be
>> the source one;
>> +
>> +endpoint node
>> +-
>> +
>> +- data-lanes: (required) an array specifying active
>> physical MIPI-CSI2
>> + data input lanes and their mapping to logical
>> lanes; the
>> + array's content is unused, only its length is
>> meaningful;
>> +
>> +- fsl,csis-hs-settle : (optional) differential receiver
>> (HS-RX) settle time;
>
> Could you calculate this, as other drivers do? It probably
> changes
> depending on the device runtime configuration.
The only reference to possible values to this parameter is
given
by table in [0], can you point me out the formula for imx7 in
the
documentation?
[0] https://community.nxp.com/thread/463777
Can't you use the values from that table ? :-) You can get the
link
speed by querying the connected subdev and reading its
V4L2_CID_PIXEL_RATE control.
Yeah, I good point to add support for others subdev's. I will try
to add your comments in a follow up series.
---
Cheers,
Rui
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v14 08/13] ARM: dts: imx7: Add video mux, csi and mipi_csi and connections
Hi Laurent,
On Sun 10 Mar 2019 at 21:41, Laurent Pinchart wrote:
Hi Rui,
Thank you for the patch.
Where have you been for the latest 14 versions? :)
This is already merged, but... follow up patches can address your
issues bellow.
On Wed, Feb 06, 2019 at 03:13:23PM +, Rui Miguel Silva
wrote:
This patch adds the device tree nodes for csi, video
multiplexer and
mipi-csi besides the graph connecting the necessary endpoints
to make
the media capture entities to work in imx7 Warp board.
Signed-off-by: Rui Miguel Silva
---
arch/arm/boot/dts/imx7s-warp.dts | 51
arch/arm/boot/dts/imx7s.dtsi | 27 +
I would have split this in two patches to make backporting
easier, but
it's not a big deal.
Please see below for a few additional comments.
2 files changed, 78 insertions(+)
diff --git a/arch/arm/boot/dts/imx7s-warp.dts
b/arch/arm/boot/dts/imx7s-warp.dts
index 23431faecaf4..358bcae7ebaf 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -277,6 +277,57 @@
status = "okay";
};
+ {
+ csi_mux {
+ compatible = "video-mux";
+ mux-controls = < 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ csi_mux_from_mipi_vc0: endpoint {
+remote-endpoint =
<_vc0_to_csi_mux>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ csi_mux_to_csi: endpoint {
+remote-endpoint =
<_from_csi_mux>;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ port {
+ csi_from_csi_mux: endpoint {
+ remote-endpoint = <_mux_to_csi>;
+ };
+ };
+};
Shouldn't these two nodes, as well as port@1 of the mipi_csi
node, be
moved to imx7d.dtsi ?
Yeah, I guess you are right here.
+
+_csi {
+ clock-frequency = <16600>;
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ fsl,csis-hs-settle = <3>;
Shouldn't this be an endpoint property ? Different sensors
connected
through different endpoints could have different timing
requirements.
Hum... I see you point, even tho the phy hs-settle is a common
control.
+
+ port@1 {
+ reg = <1>;
+
+ mipi_vc0_to_csi_mux: endpoint {
+ remote-endpoint =
<_mux_from_mipi_vc0>;
+ };
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_wdog>;
diff --git a/arch/arm/boot/dts/imx7s.dtsi
b/arch/arm/boot/dts/imx7s.dtsi
index 792efcd2caa1..01962f85cab6 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include "imx7d-pinfunc.h"
/ {
@@ -709,6 +710,17 @@
status = "disabled";
};
+ csi: csi@3071 {
+ compatible = "fsl,imx7-csi";
+ reg = <0x3071 0x1>;
+interrupts = IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < IMX7D_CLK_DUMMY>,
+ <
IMX7D_CSI_MCLK_ROOT_CLK>,
+ <
IMX7D_CLK_DUMMY>;
+clock-names = "axi", "mclk",
"dcic";
+ status = "disabled";
+ };
+
lcdif: lcdif@3073 {
compatible = "fsl,imx7d-lcdif",
"fsl,imx28-lcdif";
reg = <0x3073 0x1>;
@@ -718,6 +730,21 @@
clock-names = "pix", "axi";
status = "disabled";
};
+
+ mipi_csi: mipi-csi@3075 {
+ compatible = "fsl,imx7-mipi-csi2";
+ reg = <0x3075 0x1>;
+interrupts = IRQ_TYPE_LEVEL_HIGH>;
+clocks = <
IMX7D_IPG_ROOT_CLK>,
+ <
IMX7D_MIPI_CSI_ROOT_CLK>,
+ <
IMX7D_MIPI_DPHY_ROOT_CLK>;
+clock-names = "pclk", "wrap",
"phy";
+ power-domains = <_mipi_phy>;
+ phy-supply = <_1p0d>;
+resets = <
IMX7_RESET_MIPI_PHY_MRST>;
+ reset-names = "mrst";
+ status = "disabled";
How about already declaring port@0 here too (but obviously
without any
endoint) ?
empty port, do not know if they make much sense.
---
Cheers,
Rui
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] drivers/staging/rtl8712 - fix up non-kerneldoc comments
Building with W=1 reports (among other things) CC [M] drivers/staging/rtl8712/rtl871x_ioctl_linux.o drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1106: warning: Cannot understand * on line 1106 - I thought it was a doc line CC [M] drivers/staging/rtl8712/os_intfs.o drivers/staging/rtl8712/os_intfs.c:366: warning: Cannot understand * on line 366 - I thought it was a doc line drivers/staging/rtl8712/os_intfs.c:434: warning: Cannot understand * on line 434 - I thought it was a doc line Fix up the non-kerneldoc comments Signed-off-by: Valdis Kletnieks diff --git a/drivers/staging/rtl8712/os_intfs.c b/drivers/staging/rtl8712/os_intfs.c index 2d3f38007299..fc797c3fbaed 100644 --- a/drivers/staging/rtl8712/os_intfs.c +++ b/drivers/staging/rtl8712/os_intfs.c @@ -362,7 +362,7 @@ static void enable_video_mode(struct _adapter *padapter, int cbw40_value) r8712_fw_cmd(padapter, intcmd); } -/** +/* * * This function intends to handle the activation of an interface * i.e. when it is brought Up/Active from a Down state. @@ -430,7 +430,7 @@ static int netdev_open(struct net_device *pnetdev) return -1; } -/** +/* * * This function intends to handle the shutdown of an interface * i.e. when it is brought Down from an Up/Active state. diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c index e723357ac8c0..f49fed8cb0e7 100644 --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c @@ -1102,7 +1102,7 @@ static int r871x_wx_set_mlme(struct net_device *dev, return ret; } -/** +/* * * This function intends to handle the Set Scan command. * Currently, the request comes via Wireless Extensions' SIOCSIWSCAN ioctl. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net] staging: rtl8188eu: use is_zero_ether_addr() instead of memcmp()
On Tue, Mar 12, 2019 at 02:29:29PM +0800, maowenan wrote: > ping... > > On 2019/3/9 11:26, Mao Wenan wrote: What? You got an automated email from my patch system saying that I can not do anything with this patch until after 5.1-rc1 is out, due to the merge window. Why did that not answer the question ahead of time as to why this patch was not responded to? Also, it's only been 3 days, please relax, for a clean-up patch, it can take weeks before they are reviewed as they are obvious at the bottom of everyone's priority queue. so all is good, just wait. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net] staging: rtl8188eu: use is_zero_ether_addr() instead of memcmp()
On Tue, 2019-03-12 at 14:58 +0800, maowenan wrote:
> On 2019/3/12 14:35, Joe Perches wrote:
> > On Tue, 2019-03-12 at 14:29 +0800, maowenan wrote:
> > > ping...
> > >
> > > On 2019/3/9 11:26, Mao Wenan wrote:
> > > > Using is_zero_ether_addr() instead of directly use
> > > > memcmp() to determine if the ethernet address is all
> > > > zeros.
> > []
> > > > diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
> > > > b/drivers/staging/rtl8188eu/core/rtw_mlme.c
> > []
> > > > @@ -180,9 +180,8 @@ struct wlan_network *rtw_find_network(struct
> > > > __queue *scanned_queue, u8 *addr)
> > > > {
> > > > struct list_head *phead, *plist;
> > > > struct wlan_network *pnetwork = NULL;
> > > > - u8 zero_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
> > > >
> > > > - if (!memcmp(zero_addr, addr, ETH_ALEN)) {
> > > > + if (is_zero_ether_addr(addr)) {
> >
> > How did you verify that addr is __aligned(2)?
>
> /**
> * is_zero_ether_addr - Determine if give Ethernet address is all zeros.
> * @addr: Pointer to a six-byte array containing the Ethernet address
> *
> * Return true if the address is all zeroes.
> */
> I think they are completely equivalent functions, no need to check addr is
> __aligned(2),
> because addr may be defined as unsigned char MacAddress[ETH_ALEN]; the length
> is 6.
Perhaps you are reading old documentation.
(though the "Please note:" line is from 2013)
include/linux/etherdevice.h-/**
include/linux/etherdevice.h- * is_zero_ether_addr - Determine if give Ethernet
address is all zeros.
include/linux/etherdevice.h- * @addr: Pointer to a six-byte array containing
the Ethernet address
include/linux/etherdevice.h- *
include/linux/etherdevice.h- * Return true if the address is all zeroes.
include/linux/etherdevice.h- *
include/linux/etherdevice.h- * Please note: addr must be aligned to u16.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net] staging: rtl8188eu: use is_zero_ether_addr() instead of memcmp()
On Tue, 2019-03-12 at 14:29 +0800, maowenan wrote:
> ping...
>
> On 2019/3/9 11:26, Mao Wenan wrote:
> > Using is_zero_ether_addr() instead of directly use
> > memcmp() to determine if the ethernet address is all
> > zeros.
[]
> > diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
> > b/drivers/staging/rtl8188eu/core/rtw_mlme.c
[]
> > @@ -180,9 +180,8 @@ struct wlan_network *rtw_find_network(struct __queue
> > *scanned_queue, u8 *addr)
> > {
> > struct list_head *phead, *plist;
> > struct wlan_network *pnetwork = NULL;
> > - u8 zero_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
> >
> > - if (!memcmp(zero_addr, addr, ETH_ALEN)) {
> > + if (is_zero_ether_addr(addr)) {
How did you verify that addr is __aligned(2)?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
On Mon 11-03-19 15:15:35, Suren Baghdasaryan wrote: > On Mon, Mar 11, 2019 at 1:46 PM Sultan Alsawaf wrote: > > > > On Mon, Mar 11, 2019 at 01:10:36PM -0700, Suren Baghdasaryan wrote: > > > The idea seems interesting although I need to think about this a bit > > > more. Killing processes based on failed page allocation might backfire > > > during transient spikes in memory usage. > > > > This issue could be alleviated if tasks could be killed and have their pages > > reaped faster. Currently, Linux takes a _very_ long time to free a task's > > memory > > after an initial privileged SIGKILL is sent to a task, even with the task's > > priority being set to the highest possible (so unwanted scheduler preemption > > starving dying tasks of CPU time is not the issue at play here). I've > > frequently measured the difference in time between when a SIGKILL is sent > > for a > > task and when free_task() is called for that task to be hundreds of > > milliseconds, which is incredibly long. AFAIK, this is a problem that LMKD > > suffers from as well, and perhaps any OOM killer implementation in Linux, > > since > > you cannot evaluate effect you've had on memory pressure by killing a > > process > > for at least several tens of milliseconds. > > Yeah, killing speed is a well-known problem which we are considering > in LMKD. For example the recent LMKD change to assign process being > killed to a cpuset cgroup containing big cores cuts the kill time > considerably. This is not ideal and we are thinking about better ways > to expedite the cleanup process. If you design is relies on the speed of killing then it is fundamentally flawed AFAICT. You cannot assume anything about how quickly a task dies. It might be blocked in an uninterruptible sleep or performin an operation which takes some time. Sure, oom_reaper might help here but still. The only way to control the OOM behavior pro-actively is to throttle allocation speed. We have memcg high limit for that purpose. Along with PSI, I can imagine a reasonably working user space early oom notifications and reasonable acting upon that. -- Michal Hocko SUSE Labs ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net] staging: rtl8188eu: use is_zero_ether_addr() instead of memcmp()
On Tue, 12 Mar 2019, maowenan wrote:
>
>
> On 2019/3/12 14:35, Joe Perches wrote:
> > On Tue, 2019-03-12 at 14:29 +0800, maowenan wrote:
> >> ping...
> >>
> >> On 2019/3/9 11:26, Mao Wenan wrote:
> >>> Using is_zero_ether_addr() instead of directly use
> >>> memcmp() to determine if the ethernet address is all
> >>> zeros.
> > []
> >>> diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
> >>> b/drivers/staging/rtl8188eu/core/rtw_mlme.c
> > []
> >>> @@ -180,9 +180,8 @@ struct wlan_network *rtw_find_network(struct __queue
> >>> *scanned_queue, u8 *addr)
> >>> {
> >>> struct list_head *phead, *plist;
> >>> struct wlan_network *pnetwork = NULL;
> >>> - u8 zero_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
> >>>
> >>> - if (!memcmp(zero_addr, addr, ETH_ALEN)) {
> >>> + if (is_zero_ether_addr(addr)) {
> >
> > How did you verify that addr is __aligned(2)?
>
> /**
> * is_zero_ether_addr - Determine if give Ethernet address is all zeros.
> * @addr: Pointer to a six-byte array containing the Ethernet address
> *
> * Return true if the address is all zeroes.
> */
> I think they are completely equivalent functions, no need to check addr is
> __aligned(2),
> because addr may be defined as unsigned char MacAddress[ETH_ALEN]; the length
> is 6.
Perhaps you are confusing with eth_zero_addr, which is just a memset and
has no alignment requirements.
julia
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net] staging: rtl8188eu: use is_zero_ether_addr() instead of memcmp()
On 2019/3/12 14:35, Joe Perches wrote:
> On Tue, 2019-03-12 at 14:29 +0800, maowenan wrote:
>> ping...
>>
>> On 2019/3/9 11:26, Mao Wenan wrote:
>>> Using is_zero_ether_addr() instead of directly use
>>> memcmp() to determine if the ethernet address is all
>>> zeros.
> []
>>> diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
>>> b/drivers/staging/rtl8188eu/core/rtw_mlme.c
> []
>>> @@ -180,9 +180,8 @@ struct wlan_network *rtw_find_network(struct __queue
>>> *scanned_queue, u8 *addr)
>>> {
>>> struct list_head *phead, *plist;
>>> struct wlan_network *pnetwork = NULL;
>>> - u8 zero_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
>>>
>>> - if (!memcmp(zero_addr, addr, ETH_ALEN)) {
>>> + if (is_zero_ether_addr(addr)) {
>
> How did you verify that addr is __aligned(2)?
/**
* is_zero_ether_addr - Determine if give Ethernet address is all zeros.
* @addr: Pointer to a six-byte array containing the Ethernet address
*
* Return true if the address is all zeroes.
*/
I think they are completely equivalent functions, no need to check addr is
__aligned(2),
because addr may be defined as unsigned char MacAddress[ETH_ALEN]; the length
is 6.
>
>
>
> .
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net] staging: rtl8188eu: use is_zero_ether_addr() instead of memcmp()
ping...
On 2019/3/9 11:26, Mao Wenan wrote:
> Using is_zero_ether_addr() instead of directly use
> memcmp() to determine if the ethernet address is all
> zeros.
>
> Signed-off-by: Mao Wenan
> ---
> drivers/staging/rtl8188eu/core/rtw_mlme.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
> b/drivers/staging/rtl8188eu/core/rtw_mlme.c
> index 714f7a70ed64..beae367df93b 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
> @@ -180,9 +180,8 @@ struct wlan_network *rtw_find_network(struct __queue
> *scanned_queue, u8 *addr)
> {
> struct list_head *phead, *plist;
> struct wlan_network *pnetwork = NULL;
> - u8 zero_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
>
> - if (!memcmp(zero_addr, addr, ETH_ALEN)) {
> + if (is_zero_ether_addr(addr)) {
> pnetwork = NULL;
> goto exit;
> }
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
