RE: [PATCH v6 19/34] xlink-core: Add xlink core device tree bindings
> -Original Message- > From: Dave Hansen > Sent: Monday, April 12, 2021 2:33 PM > To: mgr...@linux.intel.com; markgr...@kernel.org; a...@arndb.de; b...@suse.de; > damien.lem...@wdc.com; dragan.cve...@xilinx.com; > gre...@linuxfoundation.org; cor...@lwn.net; palmerdabb...@google.com; > paul.walms...@sifive.com; peng@nxp.com; robh...@kernel.org; > shawn...@kernel.org; jassisinghb...@gmail.com > Cc: linux-kernel@vger.kernel.org; Kelly, Seamus ; > devicet...@vger.kernel.org > Subject: Re: [PATCH v6 19/34] xlink-core: Add xlink core device tree bindings > > On 2/12/21 2:22 PM, mgr...@linux.intel.com wrote: > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) # Copyright (c) > > +Intel Corporation. All rights reserved. > > +%YAML 1.2 > > +--- > > +$id: "http://devicetree.org/schemas/misc/intel,keembay-xlink.yaml#; > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#; > > + > > +title: Intel Keem Bay xlink > > Is there a specific reason this is dual licensed? If so, can you please > include > information about the license choice in the next post's cover letter? > > If there is no specific reason for this contribution to be dual licensed, > please make it > GPL-2.0 only. I will. I'm just waiting on some testing before making the next post. Thanks, --mark
RE: [PATCH v4 29/34] Intel tsens i2c slave driver.
> -Original Message- > From: Randy Dunlap > Sent: Sunday, January 31, 2021 6:14 PM > To: mgr...@linux.intel.com; markgr...@kernel.org; a...@arndb.de; b...@suse.de; > damien.lem...@wdc.com; dragan.cve...@xilinx.com; > gre...@linuxfoundation.org; cor...@lwn.net; palmerdabb...@google.com; > paul.walms...@sifive.com; peng@nxp.com; robh...@kernel.org; > shawn...@kernel.org; jassisinghb...@gmail.com > Cc: linux-kernel@vger.kernel.org; C, Udhayakumar > Subject: Re: [PATCH v4 29/34] Intel tsens i2c slave driver. > > On 1/29/21 6:21 PM, mgr...@linux.intel.com wrote: > > diff --git a/drivers/misc/intel_tsens/Kconfig > > b/drivers/misc/intel_tsens/Kconfig > > index 8b263fdd80c3..be8d27e81864 100644 > > --- a/drivers/misc/intel_tsens/Kconfig > > +++ b/drivers/misc/intel_tsens/Kconfig > > @@ -14,6 +14,20 @@ config INTEL_TSENS_LOCAL_HOST > > Say Y if using a processor that includes the Intel VPU such as > > Keem Bay. If unsure, say N. > > > > +config INTEL_TSENS_I2C_SLAVE > > + bool "I2C slave driver for intel tsens" > > + depends on INTEL_TSENS_LOCAL_HOST > > + depends on I2C=y && I2C_SLAVE > > + help > > + This option enables tsens I2C slave driver. > > Good, it's OK now. > The repeat v3 and then v4 confused me. Hmm, I'm confused too. I should have only sent v4 on Friday. I'll look over my history and logs to see how I could have sent to blasts one or V3 and then V4. Ugh. Sorry about mixing the V3 and V4 patches in the same batch. FWIW I make an outgoing directory and forgot to clean out the v3 patches that where there from the earlier posting. Resulting in a mixing of the old and current patch set. I'll write a script to automate the creation of the outgoing directory for next time that should correct future screw ups. I'm very sorry for the noise. --mark
RE: [PATCH v2 29/34] Intel tsens i2c slave driver.
> -Original Message- > From: Arnd Bergmann > Sent: Monday, January 25, 2021 11:45 PM > To: mgr...@linux.intel.com > Cc: Randy Dunlap ; markgr...@kernel.org; Arnd > Bergmann ; Borislav Petkov ; Damien Le Moal > ; Dragan Cvetic ; gregkh > ; Jonathan Corbet ; Leonard > Crestez ; Palmer Dabbelt > ; Paul Walmsley ; > Peng Fan ; Rob Herring ; Shawn > Guo ; Jassi Brar ; linux- > ker...@vger.kernel.org; C, Udhayakumar ; > c...@linux.intel.com > Subject: Re: [PATCH v2 29/34] Intel tsens i2c slave driver. > > On Tue, Jan 26, 2021 at 12:39 AM mark gross wrote: > > > > On Mon, Jan 11, 2021 at 11:15:06PM -0800, Randy Dunlap wrote: > > > On 1/8/21 1:25 PM, mgr...@linux.intel.com wrote: > > > > diff --git a/drivers/misc/intel_tsens/Kconfig > > > > b/drivers/misc/intel_tsens/Kconfig > > > > index 8b263fdd80c3..c2138339bd89 100644 > > > > --- a/drivers/misc/intel_tsens/Kconfig > > > > +++ b/drivers/misc/intel_tsens/Kconfig > > > > @@ -14,6 +14,20 @@ config INTEL_TSENS_LOCAL_HOST > > > > Say Y if using a processor that includes the Intel VPU such as > > > > Keem Bay. If unsure, say N. > > > > > > > > +config INTEL_TSENS_I2C_SLAVE > > > > + bool "I2C slave driver for intel tsens" > > > > > > Why bool instead of tristate? > > Becuase the I2C driver depends on a file scoped global i2c_plat_data > > instanciated in the INTELL_TSENS_LOCAL_HOST DRIVER > > (intel_tsens_thermal.[ch]) > > > > Udhaya, would you care to comment further? > > > > > + depends on INTEL_TSENS_LOCAL_HOST > > > > + select I2C > > > > + select I2C_SLAVE > > Please make this 'depends on I2C=y && I2C_SLAVE' instead of 'select' > in this case. A random driver should never force-enable another subsystem. Will do, thanks for the feedback! --mark
RE: [PATCH v3 02/34] dt-bindings: mailbox: Add Intel VPU IPC mailbox bindings
> -Original Message-
> From: Rob Herring
> Sent: Tuesday, January 26, 2021 5:45 AM
> To: Mark Gross
> Cc: markgr...@kernel.org; Arnd Bergmann ; Borislav Petkov
> ; Damien Le Moal ; Dragan Cvetic
> ; Greg Kroah-Hartman
> ; Jonathan Corbet ; Palmer
> Dabbelt ; Paul Walmsley
> ; Peng Fan ; Shawn Guo
> ; Jassi Brar ; linux-
> ker...@vger.kernel.org; Alessandrelli, Daniele
>
> Subject: Re: [PATCH v3 02/34] dt-bindings: mailbox: Add Intel VPU IPC mailbox
> bindings
>
> On Mon, Jan 25, 2021 at 11:40 PM wrote:
> >
> > From: Daniele Alessandrelli
> >
> > Add bindings for the Intel VPU IPC mailbox driver.
>
> Sigh. DT list please so it's in my queue and automated checks run.
I'm sorry about that.
Quick question, should I include the DT-list on just the patches with DT yaml
or all of the series as its got DT content?
--mark
>
> > Signed-off-by: Daniele Alessandrelli
> > ---
> > .../mailbox/intel,vpu-ipc-mailbox.yaml| 69 +++
> > MAINTAINERS | 6 ++
> > 2 files changed, 75 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mailbox/intel,vpu-ipc-mailbox.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/mailbox/intel,vpu-ipc-mailbox.yaml
> > b/Documentation/devicetree/bindings/mailbox/intel,vpu-ipc-mailbox.yaml
> > new file mode 100644
> > index ..923a6d619a64
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/intel,vpu-ipc-mailbox.
> > +++ yaml
> > @@ -0,0 +1,69 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) # Copyright
> > +(c) 2020 Intel Corporation %YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/mailbox/intel,vpu-ipc-mailbox.yaml#;
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> > +
> > +title: Intel VPU IPC mailbox
> > +
> > +maintainers:
> > + - Daniele Alessandrelli
> > +
> > +description: |
> > + Intel VPU SoCs like Keem Bay have hardware FIFOs to enable
> > +Inter-Processor
> > + Communication (IPC) between the CPU and the VPU.
> > +
> > + Specifically, there is one HW FIFO for the CPU (aka Application
> > + Processor -
> > + AP) and one for the VPU. Each FIFO can hold 128 entries of 32 bits
> > + each. A "FIFO-not-empty" interrupt is raised every time there is at
> > + least a message in the FIFO. The CPU FIFO raises interrupts to the
> > + CPU, while the VPU FIFO raises interrupts to VPU. When the CPU
> > + wants to send a message to the VPU it writes to the VPU FIFO,
> > + similarly, when the VPU want to send a message to the CPU, it writes to
> > the
> CPU FIFO.
> > +
> > + Refer to ./mailbox.txt for generic information about mailbox
> > + device-tree bindings.
> > +
> > +properties:
> > + compatible:
> > +const: intel,vpu-ipc-mailbox
> > +
> > + reg:
> > +items:
> > + - description: The CPU FIFO registers
> > + - description: The VPU FIFO registers
> > +
> > + reg-names:
> > +items:
> > + - const: cpu_fifo
> > + - const: vpu_fifo
> > +
> > + interrupts:
> > +items:
> > + - description: CPU FIFO-not-empty interrupt
> > +
> > + "#mbox-cells":
> > +const: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - interrupts
> > + - "#mbox-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +vpu_ipc_mailbox@203300f0 {
> > +compatible = "intel,vpu-ipc-mailbox";
> > +#mbox-cells = <1>;
> > +reg = <0x203300f0 0x310>,
> > + <0x208200f0 0x310>;
> > +reg-names = "cpu_fifo", "vpu_fifo";
> > +interrupts = ;
> > +};
> > diff --git a/MAINTAINERS b/MAINTAINERS index
> > 992fe3b0900a..2b82526a00dc 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9181,6 +9181,12 @@ L: platform-driver-...@vger.kernel.org
> > S: Maintained
> > F: drivers/platform/x86/intel-vbtn.c
> >
> > +INTEL VPU IPC MAILBOX
> > +M: Daniele Alessandrelli
> > +M: Mark Gross
> > +S: Supported
> > +F: Documentation/devicetree/bindings/mailbox/intel,vpu-ipc-mailbox.yaml
> > +
> > INTEL WIRELESS 3945ABG/BG, 4965AGN (iwlegacy)
> > M: Stanislaw Gruszka
> > L: linux-wirel...@vger.kernel.org
> > --
> > 2.17.1
> >
RE: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module
> -Original Message- > From: Greg KH > Sent: Friday, December 11, 2020 12:23 AM > To: Daniele Alessandrelli > Cc: Alessandrelli, Daniele ; > mgr...@linux.intel.com; markgr...@kernel.org; a...@arndb.de; > robh...@kernel.org; linux-kernel@vger.kernel.org; sumit.sem...@linaro.org; > christian.koe...@amd.com > Subject: Re: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module > > On Thu, Dec 10, 2020 at 06:38:24PM +, Daniele Alessandrelli wrote: > > On Tue, 2020-12-08 at 20:48 +0100, Greg KH wrote: > > > On Tue, Dec 08, 2020 at 06:59:09PM +, Daniele Alessandrelli wrote: > > > > Hi Greg, > > > > > > > > Thanks for your feedback. > > > > > > > > On Wed, 2020-12-02 at 07:19 +0100, Greg KH wrote: > > > > > On Tue, Dec 01, 2020 at 02:34:52PM -0800, mgr...@linux.intel.com > wrote: > > > > > > From: Daniele Alessandrelli > > > > > > > > > > > > On the Intel Movidius SoC code named Keem Bay, communication > > > > > > between the Computing Sub-System (CSS), i.e., the CPU, and the > > > > > > Multimedia Sub-System (MSS), i.e., the VPU is enabled by the > > > > > > Keem Bay Inter-Processor Communication (IPC) mechanism. > > > > > > > > > > > > Add the driver for using Keem Bay IPC from within the Linux Kernel. > > > > > > > > > > > > Keem Bay IPC uses the following terminology: > > > > > > > > > > > > - Node:A processing entity that can use the IPC to communicate; > > > > > >currently, we just have two nodes, CPU (CSS) and VPU (MSS). > > > > > > > > > > > > - Link:Two nodes that can communicate over IPC form an IPC link > > > > > >(currently, we just have one link, the one between the CPU > > > > > >and VPU). > > > > > > > > > > > > - Channel: An IPC link can provide multiple IPC channels. IPC > > > > > > channels > > > > > >allow communication multiplexing, i.e., the same IPC link can > > > > > >be used by different applications for different > > > > > >communications. Each channel is identified by a channel ID, > > > > > >which must be unique within a single IPC link. Channels are > > > > > >divided in two categories, High-Speed (HS) channels and > > > > > >General-Purpose (GP) channels. HS channels have higher > > > > > >priority over GP channels. > > > > > > > > > > > > Keem Bay IPC mechanism is based on shared memory and hardware > FIFOs. > > > > > > Both the CPU and the VPU have their own hardware FIFO. When > > > > > > the CPU wants to send an IPC message to the VPU, it writes to > > > > > > the VPU FIFO (MSS FIFO); similarly, when MSS wants to send an > > > > > > IPC message to the CPU, it writes to the CPU FIFO (CSS FIFO). > > > > > > > > > > > > A FIFO entry is simply a pointer to an IPC buffer (aka IPC > > > > > > header) stored in a portion of memory shared between the CPU and > the VPU. > > > > > > Specifically, the FIFO entry contains the (VPU) physical > > > > > > address of the IPC buffer being transferred. > > > > > > > > > > > > In turn, the IPC buffer contains the (VPU) physical address of > > > > > > the payload (which must be located in shared memory too) as > > > > > > well as other information (payload size, IPC channel ID, etc.). > > > > > > > > > > > > Each IPC node instantiates a pool of IPC buffers from its own > > > > > > IPC buffer memory region. When instantiated, IPC buffers are > > > > > > marked as free. When the node needs to send an IPC message, it > > > > > > gets the first free buffer it finds (from its own pool), marks > > > > > > it as allocated (used), and puts its physical address into the > > > > > > IPC FIFO of the destination node. The destination node (which > > > > > > is notified by an interrupt when there are entries pending in > > > > > > its FIFO) extract the physical address from the FIFO and > > > > > > process the IPC buffer, marking it as free once done (so that the > > > > > > sender > can reuse the buffer). > > > > > > > > > > Any reason you can't use the dmabuf interface for these memory > > > > > buffers you are creating and having to manage "by hand"? I > > > > > thought that was what the kernel was wanting to unify on such > > > > > that individual drivers/subsystems didn't have to do this on their > > > > > own. > > > > > > > > My understanding is that the dmabuf interface is used to share DMA > > > > buffers across different drivers, while these buffers are used > > > > only internally to the IPC driver (and exchanged only with the VPU > > > > firmware). They basically are packet headers that are sent to the VPU. > > > > > > There's no reason you couldn't use these to share your buffers > > > "internally" as well, because you have the same lifetime rules and > > > accounting and all other sorts of things you have to handle, right? > > > Why rewrite something like this when you should take advantage of > > > common code instead? > > > > I looked at dma-buf again, but I'm still failing to see how we can use > > it in this driver :/ > > > > The problem
RE: [PATCH 16/22] xlink-ipc: Add xlink ipc driver
> -Original Message- > From: gre...@linuxfoundation.org > Sent: Friday, December 11, 2020 4:14 AM > To: Kelly, Seamus > Cc: Joe Perches ; mgr...@linux.intel.com; > markgr...@kernel.org; a...@arndb.de; b...@suse.de; > damien.lem...@wdc.com; dragan.cve...@xilinx.com; cor...@lwn.net; > leonard.cres...@nxp.com; palmerdabb...@google.com; > paul.walms...@sifive.com; peng@nxp.com; robh...@kernel.org; > shawn...@kernel.org; linux-kernel@vger.kernel.org; linux- > d...@vger.kernel.org; Ryan Carnaghi > Subject: Re: [PATCH 16/22] xlink-ipc: Add xlink ipc driver > > On Fri, Dec 11, 2020 at 11:33:02AM +, Kelly, Seamus wrote: > > This e-mail and any attachments may contain confidential material for > > the sole use of the intended recipient(s). Any review or distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. Must be something Seamus is using that knows when emails go outside. I would have caught this on our internal mock reviews otherwise. > > Now deleted! > > This footer is incompatible with Linux kernel development, please remove it in > order for us to read your emails and do anything with them. Yes, I know. > > I can't believe that Intel still has this problem, after all of these years... I'll add a warning about this in my training collateral and have all engineers I work with on this type of upstreaming send a test email to markgr...@kernel.org so I can see if they have such legal clauses appended to out-bound email that is not visible to internal recipients. I'll fix this. Sorry, --mark
RE: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module
> -Original Message- > From: Greg KH > Sent: Saturday, December 5, 2020 12:40 AM > To: mark gross > Cc: markgr...@kernel.org; a...@arndb.de; b...@suse.de; > damien.lem...@wdc.com; dragan.cve...@xilinx.com; cor...@lwn.net; > leonard.cres...@nxp.com; palmerdabb...@google.com; > paul.walms...@sifive.com; peng@nxp.com; robh...@kernel.org; > shawn...@kernel.org; linux-kernel@vger.kernel.org; Alessandrelli, Daniele > ; Iyer, Sundar > Subject: Re: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module > > On Fri, Dec 04, 2020 at 07:35:17PM -0800, mark gross wrote: > > On Wed, Dec 02, 2020 at 08:01:18PM +0100, Greg KH wrote: > > > On Wed, Dec 02, 2020 at 09:42:00AM -0800, mark gross wrote: > > > > On Wed, Dec 02, 2020 at 07:16:20AM +0100, Greg KH wrote: > > > > > On Tue, Dec 01, 2020 at 02:34:52PM -0800, mgr...@linux.intel.com > > > > > wrote: > > > > > > --- a/MAINTAINERS > > > > > > +++ b/MAINTAINERS > > > > > > @@ -8955,6 +8955,14 @@ M: Deepak Saxena > > > > > > S: Maintained > > > > > > F: drivers/char/hw_random/ixp4xx-rng.c > > > > > > > > > > > > +INTEL KEEM BAY IPC DRIVER > > > > > > +M: Daniele Alessandrelli > > > > > > +M: Mark Gross > > > > > > +S: Maintained > > > > > > +F: Documentation/devicetree/bindings/soc/intel/intel,keembay- > ipc.yaml > > > > > > +F: drivers/soc/intel/keembay-ipc.c > > > > > > +F: include/linux/soc/intel/keembay-ipc.h > > > > > > > > > > Sad that Intel is not going to actually pay you all to do this > > > > > maintenance work for a brand new subsystem you are wanting to > > > > > add to the tree :( > > > > I thought adding my name to these maintainer items would help with > > > > continuity as the individual engineers tend to move on to other things > > > > over > time. > > > > > > > > While I'm paid for a number of things at intel this is one of > > > > them. My role is as stable as I choose it to be at the point I'm > > > > at in my Intel career and the business unit I'm now part of. We > > > > can leave my name off if that would be better. > > > > > > > > Even if I'm not a VPU IP domain expert like Daniele is I can still > > > > chase down the experts as needed after Daniele grows into other things > > > > over > time. > > > > > > I'm not objecting to your, or anyone else's name on this at all. > > > I'm just asking about Intel's support for this new codebase being added. > > > Having a new subsystem from a major company and not have someone > > > paid to actually maintain it seems really odd to me. > > > > > > That's all. If that's Intel's stance, that's fine, just wanted to > > > clarify it is correct as I know some people at Intel have been > > > confused recently about just what the S: field means. > > I've been following up on whether the status field should be > > "Supported" or "Maintained" at this time. For this current > > instantiation of the VPU enabling under review here I think Maintained > > most appropriate. There are a good number of people who look after it. > > > > However; I have learned that the instantiations of the VPU after keem > > bay and its follow on SoC will include an evolution of this stack and > > between now and when those get close to landing that evolved version will > become "Supported". > > > > Given this, would it be more appropriate to put this stack into > > staging for a while? > > drivers/staging/ is for code that for some reason is not good enough to be > merged > to the "right" place in the kernel tree, and you need community help to get it > cleaned up because you can not do it yourself. > > Is that the case here? If not, then no, it should not go into > drivers/staging/. That is not the case here. Lets proceed as we are on this then. Thanks! --mark
RE: [PATCH] tlclk: lean an indentation issue, remove extraneous tabs
Looks cool to me.
Reviewed-by
--mark
> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com]
> Sent: Tuesday, October 30, 2018 4:57 AM
> To: Gross, Mark ; Arnd Bergmann ;
> Greg Kroah-Hartman
> Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] tlclk: lean an indentation issue, remove extraneous tabs
>
> From: Colin Ian King
>
> Trivial fix to clean up an indentation issue, remove tabs
>
> Signed-off-by: Colin Ian King
> ---
> drivers/char/tlclk.c | 84 ++--
> 1 file changed, 42 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/char/tlclk.c b/drivers/char/tlclk.c index
> 8eeb4190207d..a0f2c0506176 100644
> --- a/drivers/char/tlclk.c
> +++ b/drivers/char/tlclk.c
> @@ -506,27 +506,27 @@ static ssize_t
> store_select_amcb2_transmit_clock(struct device *d,
>
> val = (unsigned char)tmp;
> spin_lock_irqsave(_lock, flags);
> - if ((val == CLK_8kHz) || (val == CLK_16_384MHz)) {
> - SET_PORT_BITS(TLCLK_REG3, 0xc7, 0x28);
> - SET_PORT_BITS(TLCLK_REG1, 0xfb, ~val);
> - } else if (val >= CLK_8_592MHz) {
> - SET_PORT_BITS(TLCLK_REG3, 0xc7, 0x38);
> - switch (val) {
> - case CLK_8_592MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 2);
> - break;
> - case CLK_11_184MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 0);
> - break;
> - case CLK_34_368MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 3);
> - break;
> - case CLK_44_736MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 1);
> - break;
> - }
> - } else
> - SET_PORT_BITS(TLCLK_REG3, 0xc7, val << 3);
> + if ((val == CLK_8kHz) || (val == CLK_16_384MHz)) {
> + SET_PORT_BITS(TLCLK_REG3, 0xc7, 0x28);
> + SET_PORT_BITS(TLCLK_REG1, 0xfb, ~val);
> + } else if (val >= CLK_8_592MHz) {
> + SET_PORT_BITS(TLCLK_REG3, 0xc7, 0x38);
> + switch (val) {
> + case CLK_8_592MHz:
> + SET_PORT_BITS(TLCLK_REG0, 0xfc, 2);
> + break;
> + case CLK_11_184MHz:
> + SET_PORT_BITS(TLCLK_REG0, 0xfc, 0);
> + break;
> + case CLK_34_368MHz:
> + SET_PORT_BITS(TLCLK_REG0, 0xfc, 3);
> + break;
> + case CLK_44_736MHz:
> + SET_PORT_BITS(TLCLK_REG0, 0xfc, 1);
> + break;
> + }
> + } else
> + SET_PORT_BITS(TLCLK_REG3, 0xc7, val << 3);
>
> spin_unlock_irqrestore(_lock, flags);
>
> @@ -548,27 +548,27 @@ static ssize_t
> store_select_amcb1_transmit_clock(struct device *d,
>
> val = (unsigned char)tmp;
> spin_lock_irqsave(_lock, flags);
> - if ((val == CLK_8kHz) || (val == CLK_16_384MHz)) {
> - SET_PORT_BITS(TLCLK_REG3, 0xf8, 0x5);
> - SET_PORT_BITS(TLCLK_REG1, 0xfb, ~val);
> - } else if (val >= CLK_8_592MHz) {
> - SET_PORT_BITS(TLCLK_REG3, 0xf8, 0x7);
> - switch (val) {
> - case CLK_8_592MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 2);
> - break;
> - case CLK_11_184MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 0);
> - break;
> - case CLK_34_368MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 3);
> - break;
> - case CLK_44_736MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 1);
> - break;
> - }
> - } else
> - SET_PORT_BITS(TLCLK_REG3, 0xf8, val);
> + if ((val == CLK_8kHz) || (val == CLK_16_384MHz)) {
> + SET_PORT_BITS(TLCLK_REG3, 0xf8, 0x5);
> + SET_PORT_BITS(TLCLK_REG1, 0xfb, ~val);
> + } else if (val >= CLK_8_592MHz) {
> + SET_PORT_BITS(TLCLK_REG3, 0xf8, 0x7);
> + switch (val) {
> + case CLK_8_592MHz:
> + SET_PORT_BITS(TLCLK_REG0, 0xfc, 2);
> + break;
>
RE: [PATCH] tlclk: lean an indentation issue, remove extraneous tabs
Looks cool to me.
Reviewed-by
--mark
> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com]
> Sent: Tuesday, October 30, 2018 4:57 AM
> To: Gross, Mark ; Arnd Bergmann ;
> Greg Kroah-Hartman
> Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] tlclk: lean an indentation issue, remove extraneous tabs
>
> From: Colin Ian King
>
> Trivial fix to clean up an indentation issue, remove tabs
>
> Signed-off-by: Colin Ian King
> ---
> drivers/char/tlclk.c | 84 ++--
> 1 file changed, 42 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/char/tlclk.c b/drivers/char/tlclk.c index
> 8eeb4190207d..a0f2c0506176 100644
> --- a/drivers/char/tlclk.c
> +++ b/drivers/char/tlclk.c
> @@ -506,27 +506,27 @@ static ssize_t
> store_select_amcb2_transmit_clock(struct device *d,
>
> val = (unsigned char)tmp;
> spin_lock_irqsave(_lock, flags);
> - if ((val == CLK_8kHz) || (val == CLK_16_384MHz)) {
> - SET_PORT_BITS(TLCLK_REG3, 0xc7, 0x28);
> - SET_PORT_BITS(TLCLK_REG1, 0xfb, ~val);
> - } else if (val >= CLK_8_592MHz) {
> - SET_PORT_BITS(TLCLK_REG3, 0xc7, 0x38);
> - switch (val) {
> - case CLK_8_592MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 2);
> - break;
> - case CLK_11_184MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 0);
> - break;
> - case CLK_34_368MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 3);
> - break;
> - case CLK_44_736MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 1);
> - break;
> - }
> - } else
> - SET_PORT_BITS(TLCLK_REG3, 0xc7, val << 3);
> + if ((val == CLK_8kHz) || (val == CLK_16_384MHz)) {
> + SET_PORT_BITS(TLCLK_REG3, 0xc7, 0x28);
> + SET_PORT_BITS(TLCLK_REG1, 0xfb, ~val);
> + } else if (val >= CLK_8_592MHz) {
> + SET_PORT_BITS(TLCLK_REG3, 0xc7, 0x38);
> + switch (val) {
> + case CLK_8_592MHz:
> + SET_PORT_BITS(TLCLK_REG0, 0xfc, 2);
> + break;
> + case CLK_11_184MHz:
> + SET_PORT_BITS(TLCLK_REG0, 0xfc, 0);
> + break;
> + case CLK_34_368MHz:
> + SET_PORT_BITS(TLCLK_REG0, 0xfc, 3);
> + break;
> + case CLK_44_736MHz:
> + SET_PORT_BITS(TLCLK_REG0, 0xfc, 1);
> + break;
> + }
> + } else
> + SET_PORT_BITS(TLCLK_REG3, 0xc7, val << 3);
>
> spin_unlock_irqrestore(_lock, flags);
>
> @@ -548,27 +548,27 @@ static ssize_t
> store_select_amcb1_transmit_clock(struct device *d,
>
> val = (unsigned char)tmp;
> spin_lock_irqsave(_lock, flags);
> - if ((val == CLK_8kHz) || (val == CLK_16_384MHz)) {
> - SET_PORT_BITS(TLCLK_REG3, 0xf8, 0x5);
> - SET_PORT_BITS(TLCLK_REG1, 0xfb, ~val);
> - } else if (val >= CLK_8_592MHz) {
> - SET_PORT_BITS(TLCLK_REG3, 0xf8, 0x7);
> - switch (val) {
> - case CLK_8_592MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 2);
> - break;
> - case CLK_11_184MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 0);
> - break;
> - case CLK_34_368MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 3);
> - break;
> - case CLK_44_736MHz:
> - SET_PORT_BITS(TLCLK_REG0, 0xfc, 1);
> - break;
> - }
> - } else
> - SET_PORT_BITS(TLCLK_REG3, 0xf8, val);
> + if ((val == CLK_8kHz) || (val == CLK_16_384MHz)) {
> + SET_PORT_BITS(TLCLK_REG3, 0xf8, 0x5);
> + SET_PORT_BITS(TLCLK_REG1, 0xfb, ~val);
> + } else if (val >= CLK_8_592MHz) {
> + SET_PORT_BITS(TLCLK_REG3, 0xf8, 0x7);
> + switch (val) {
> + case CLK_8_592MHz:
> + SET_PORT_BITS(TLCLK_REG0, 0xfc, 2);
> + break;
>
RE: [PATCH 0/3] constify char attribute_group structures
Sounds good to me. --mark > -Original Message- > From: Arvind Yadav [mailto:arvind.yadav...@gmail.com] > Sent: Wednesday, August 2, 2017 10:35 PM > To: Gross, Mark <mark.gr...@intel.com>; a...@arndb.de; > gre...@linuxfoundation.org > Cc: linux-kernel@vger.kernel.org > Subject: Re: [PATCH 0/3] constify char attribute_group structures > > Hi Mark, > > > On Wednesday 02 August 2017 11:26 PM, Gross, Mark wrote: > > Why stop at these 3 users of attribute_group? > I am doing for all. This changes is only for char user. Few patch are under > review and few are merged. Rest all I will send. > > ~arvind > > --mark > > > > -Original Message- > > From: Arvind Yadav [mailto:arvind.yadav...@gmail.com] > > Sent: Wednesday, August 2, 2017 4:19 AM > > To: a...@arndb.de; gre...@linuxfoundation.org; Gross, Mark > > <mark.gr...@intel.com> > > Cc: linux-kernel@vger.kernel.org > > Subject: [PATCH 0/3] constify char attribute_group structures > > > > attribute_group are not supposed to change at runtime. All functions working > with attribute_group provided by work with const > attribute_group. So mark the non-const structs as const. > > > > Arvind Yadav (3): > >[PATCH 1/3] char: tlclk: constify attribute_group structures. > >[PATCH 2/3] char: tpm: constify attribute_group structures. > >[PATCH 3/3] char: virtio: constify attribute_group structures. > > > > drivers/char/tlclk.c | 2 +- > > drivers/char/tpm/tpm_ppi.c| 2 +- > > drivers/char/virtio_console.c | 2 +- > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > > -- > > 1.9.1 > >
RE: [PATCH 0/3] constify char attribute_group structures
Sounds good to me. --mark > -Original Message- > From: Arvind Yadav [mailto:arvind.yadav...@gmail.com] > Sent: Wednesday, August 2, 2017 10:35 PM > To: Gross, Mark ; a...@arndb.de; > gre...@linuxfoundation.org > Cc: linux-kernel@vger.kernel.org > Subject: Re: [PATCH 0/3] constify char attribute_group structures > > Hi Mark, > > > On Wednesday 02 August 2017 11:26 PM, Gross, Mark wrote: > > Why stop at these 3 users of attribute_group? > I am doing for all. This changes is only for char user. Few patch are under > review and few are merged. Rest all I will send. > > ~arvind > > --mark > > > > -Original Message- > > From: Arvind Yadav [mailto:arvind.yadav...@gmail.com] > > Sent: Wednesday, August 2, 2017 4:19 AM > > To: a...@arndb.de; gre...@linuxfoundation.org; Gross, Mark > > > > Cc: linux-kernel@vger.kernel.org > > Subject: [PATCH 0/3] constify char attribute_group structures > > > > attribute_group are not supposed to change at runtime. All functions working > with attribute_group provided by work with const > attribute_group. So mark the non-const structs as const. > > > > Arvind Yadav (3): > >[PATCH 1/3] char: tlclk: constify attribute_group structures. > >[PATCH 2/3] char: tpm: constify attribute_group structures. > >[PATCH 3/3] char: virtio: constify attribute_group structures. > > > > drivers/char/tlclk.c | 2 +- > > drivers/char/tpm/tpm_ppi.c| 2 +- > > drivers/char/virtio_console.c | 2 +- > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > > -- > > 1.9.1 > >
RE: [PATCH 1/3] char: tlclk: constify attribute_group structures.
The driver doesn't seem to touch the name field after its defined it looks ok
functionally.
Note: I am not a fan of const declarations in the C language. It's too
complicated when we get into casting and pointers to structures.
I'm not sure there is a lot of value in being pedantic on a few users of
attribute_group structures. I'm thinking this change should be all or nothing
and change core function prototypes to create warnings if they are not used
with properly defined const 's. Otherwise this is just a cosmetic change of
minimal value to a subset of drivers.
FWIW there does seem to be a good number (cscope finds 1700+) of
attribute_group users across the kernel and a good number of them are not using
const. If you go down this pedantic path I don't think you should at just 3
drivers.
Reviewed-by: mark gross <mark.gr...@intel.com>
--mark
> -Original Message-
> From: Arvind Yadav [mailto:arvind.yadav...@gmail.com]
> Sent: Wednesday, August 2, 2017 4:19 AM
> To: a...@arndb.de; gre...@linuxfoundation.org; Gross, Mark
> <mark.gr...@intel.com>
> Cc: linux-kernel@vger.kernel.org
> Subject: [PATCH 1/3] char: tlclk: constify attribute_group structures.
>
> attribute_group are not supposed to change at runtime. All functions working
> with attribute_group provided by work with const
> attribute_group. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav <arvind.yadav...@gmail.com>
> ---
> drivers/char/tlclk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/tlclk.c b/drivers/char/tlclk.c index
> 572a517..6210bff
> 100644
> --- a/drivers/char/tlclk.c
> +++ b/drivers/char/tlclk.c
> @@ -766,7 +766,7 @@ static ssize_t store_reset (struct device *d,
> NULL
> };
>
> -static struct attribute_group tlclk_attribute_group = {
> +static const struct attribute_group tlclk_attribute_group = {
> .name = NULL, /* put in device directory */
> .attrs = tlclk_sysfs_entries,
> };
> --
> 1.9.1
RE: [PATCH 1/3] char: tlclk: constify attribute_group structures.
The driver doesn't seem to touch the name field after its defined it looks ok
functionally.
Note: I am not a fan of const declarations in the C language. It's too
complicated when we get into casting and pointers to structures.
I'm not sure there is a lot of value in being pedantic on a few users of
attribute_group structures. I'm thinking this change should be all or nothing
and change core function prototypes to create warnings if they are not used
with properly defined const 's. Otherwise this is just a cosmetic change of
minimal value to a subset of drivers.
FWIW there does seem to be a good number (cscope finds 1700+) of
attribute_group users across the kernel and a good number of them are not using
const. If you go down this pedantic path I don't think you should at just 3
drivers.
Reviewed-by: mark gross
--mark
> -Original Message-
> From: Arvind Yadav [mailto:arvind.yadav...@gmail.com]
> Sent: Wednesday, August 2, 2017 4:19 AM
> To: a...@arndb.de; gre...@linuxfoundation.org; Gross, Mark
>
> Cc: linux-kernel@vger.kernel.org
> Subject: [PATCH 1/3] char: tlclk: constify attribute_group structures.
>
> attribute_group are not supposed to change at runtime. All functions working
> with attribute_group provided by work with const
> attribute_group. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav
> ---
> drivers/char/tlclk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/tlclk.c b/drivers/char/tlclk.c index
> 572a517..6210bff
> 100644
> --- a/drivers/char/tlclk.c
> +++ b/drivers/char/tlclk.c
> @@ -766,7 +766,7 @@ static ssize_t store_reset (struct device *d,
> NULL
> };
>
> -static struct attribute_group tlclk_attribute_group = {
> +static const struct attribute_group tlclk_attribute_group = {
> .name = NULL, /* put in device directory */
> .attrs = tlclk_sysfs_entries,
> };
> --
> 1.9.1
RE: [PATCH 0/3] constify char attribute_group structures
Why stop at these 3 users of attribute_group? --mark -Original Message- From: Arvind Yadav [mailto:arvind.yadav...@gmail.com] Sent: Wednesday, August 2, 2017 4:19 AM To: a...@arndb.de; gre...@linuxfoundation.org; Gross, Mark <mark.gr...@intel.com> Cc: linux-kernel@vger.kernel.org Subject: [PATCH 0/3] constify char attribute_group structures attribute_group are not supposed to change at runtime. All functions working with attribute_group provided by work with const attribute_group. So mark the non-const structs as const. Arvind Yadav (3): [PATCH 1/3] char: tlclk: constify attribute_group structures. [PATCH 2/3] char: tpm: constify attribute_group structures. [PATCH 3/3] char: virtio: constify attribute_group structures. drivers/char/tlclk.c | 2 +- drivers/char/tpm/tpm_ppi.c| 2 +- drivers/char/virtio_console.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- 1.9.1
RE: [PATCH 0/3] constify char attribute_group structures
Why stop at these 3 users of attribute_group? --mark -Original Message- From: Arvind Yadav [mailto:arvind.yadav...@gmail.com] Sent: Wednesday, August 2, 2017 4:19 AM To: a...@arndb.de; gre...@linuxfoundation.org; Gross, Mark Cc: linux-kernel@vger.kernel.org Subject: [PATCH 0/3] constify char attribute_group structures attribute_group are not supposed to change at runtime. All functions working with attribute_group provided by work with const attribute_group. So mark the non-const structs as const. Arvind Yadav (3): [PATCH 1/3] char: tlclk: constify attribute_group structures. [PATCH 2/3] char: tpm: constify attribute_group structures. [PATCH 3/3] char: virtio: constify attribute_group structures. drivers/char/tlclk.c | 2 +- drivers/char/tpm/tpm_ppi.c| 2 +- drivers/char/virtio_console.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- 1.9.1
RE: [PATCH 19/86] edac/e7xxx: use uapi/linux/pci_ids.h directly
ack > -Original Message- > From: Michael S. Tsirkin [mailto:m...@redhat.com] > Sent: Sunday, March 29, 2015 6:39 AM > To: linux-kernel@vger.kernel.org > Cc: Gross, Mark; Doug Thompson; Borislav Petkov; Mauro Carvalho Chehab; > linux-e...@vger.kernel.org > Subject: [PATCH 19/86] edac/e7xxx: use uapi/linux/pci_ids.h directly > > Header moved from linux/pci_ids.h to uapi/linux/pci_ids.h, use the new > header directly so we can drop the wrapper in include/linux/pci_ids.h. > > Signed-off-by: Michael S. Tsirkin > --- > drivers/edac/e752x_edac.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/edac/e752x_edac.c b/drivers/edac/e752x_edac.c index > b2d7138..91c8441 100644 > --- a/drivers/edac/e752x_edac.c > +++ b/drivers/edac/e752x_edac.c > @@ -22,7 +22,7 @@ > #include > #include > #include > -#include > +#include > #include > #include "edac_core.h" > > -- > MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 19/86] edac/e7xxx: use uapi/linux/pci_ids.h directly
ack -Original Message- From: Michael S. Tsirkin [mailto:m...@redhat.com] Sent: Sunday, March 29, 2015 6:39 AM To: linux-kernel@vger.kernel.org Cc: Gross, Mark; Doug Thompson; Borislav Petkov; Mauro Carvalho Chehab; linux-e...@vger.kernel.org Subject: [PATCH 19/86] edac/e7xxx: use uapi/linux/pci_ids.h directly Header moved from linux/pci_ids.h to uapi/linux/pci_ids.h, use the new header directly so we can drop the wrapper in include/linux/pci_ids.h. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- drivers/edac/e752x_edac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/edac/e752x_edac.c b/drivers/edac/e752x_edac.c index b2d7138..91c8441 100644 --- a/drivers/edac/e752x_edac.c +++ b/drivers/edac/e752x_edac.c @@ -22,7 +22,7 @@ #include linux/module.h #include linux/init.h #include linux/pci.h -#include linux/pci_ids.h +#include uapi/linux/pci_ids.h #include linux/edac.h #include edac_core.h -- MST -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] MAINTAINERS: INTEL MID SOC: add maintainer
Signed-off-by: markgross --mgross The developer experience is our product > -Original Message- > From: David Cohen [mailto:david.a.co...@linux.intel.com] > Sent: Thursday, April 17, 2014 7:39 PM > To: h...@zytor.com; mi...@redhat.com; t...@linutronix.de; > x...@kernel.org > Cc: linux-kernel@vger.kernel.org; gno...@lxorguk.ukuu.org.uk; David > Cohen; Gross, Mark > Subject: [PATCH] MAINTAINERS: INTEL MID SOC: add maintainer > > This patch adds official maintainer for low power Intel MID SoC platforms. > > Signed-off-by: David Cohen > Cc: Mark Gross > --- > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 6dc67b1fdb50..b6056f33cb4d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5447,6 +5447,14 @@ W: logfs.org > S: Maintained > F: fs/logfs/ > > +LOW-POWER INTEL MID SOC SUPPORT > +M: David Cohen > +S: Supported > +F: arch/x86/platform/intel-mid/ > +F: arch/x86/pci/intel_mid_pci.c > +F: arch/x86/include/asm/intel-mid.h > +F: arch/x86/include/asm/intel_mid*.h > + > LPC32XX MACHINE SUPPORT > M: Roland Stigge > L: linux-arm-ker...@lists.infradead.org (moderated for non- > subscribers) > -- > 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] MAINTAINERS: INTEL MID SOC: add maintainer
Signed-off-by: markgross mgr...@linux.intel.com --mgross The developer experience is our product -Original Message- From: David Cohen [mailto:david.a.co...@linux.intel.com] Sent: Thursday, April 17, 2014 7:39 PM To: h...@zytor.com; mi...@redhat.com; t...@linutronix.de; x...@kernel.org Cc: linux-kernel@vger.kernel.org; gno...@lxorguk.ukuu.org.uk; David Cohen; Gross, Mark Subject: [PATCH] MAINTAINERS: INTEL MID SOC: add maintainer This patch adds official maintainer for low power Intel MID SoC platforms. Signed-off-by: David Cohen david.a.co...@linux.intel.com Cc: Mark Gross mark.gr...@intel.com --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6dc67b1fdb50..b6056f33cb4d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5447,6 +5447,14 @@ W: logfs.org S: Maintained F: fs/logfs/ +LOW-POWER INTEL MID SOC SUPPORT +M: David Cohen david.a.co...@linux.intel.com +S: Supported +F: arch/x86/platform/intel-mid/ +F: arch/x86/pci/intel_mid_pci.c +F: arch/x86/include/asm/intel-mid.h +F: arch/x86/include/asm/intel_mid*.h + LPC32XX MACHINE SUPPORT M: Roland Stigge sti...@antcom.de L: linux-arm-ker...@lists.infradead.org (moderated for non- subscribers) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/4] net: rfkill: gpio: remove gpio names
Please know that no one should not consider me an authority on ACPI at this
time. But, I have some comments / context / thoughts below.
Also I apologize in advance for any email formatting issues caused by replying
to this via my work exchange account / outlook client. Folks can use
mgr...@linux.intel.com to avoid outlook-isms from me in the future.
> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: Tuesday, February 25, 2014 1:14 AM
> To: Stephen Warren; Alexandre Courbot; Grant Likely;
> devicet...@vger.kernel.org
> Cc: Chen-Yu Tsai; Heikki Krogerus; Johannes Berg; David S. Miller; Rhyland
> Klein; linux-wireless; netdev; linux-kernel; Arnd Bergmann; Gross, Mark
> Subject: Re: [PATCH 2/4] net: rfkill: gpio: remove gpio names
>
> On Fri, Feb 21, 2014 at 6:35 AM, Stephen Warren
> wrote:
> > On 02/20/2014 06:55 PM, Chen-Yu Tsai wrote:
>
> >> That's correct. However using con_id to pass this results in
> >> different behavior across DT and ACPI. A better way is to export the
> >> labeling function so consumers can set meaningful labels themselves.
> >
> > But this code is the consumer of those GPIOs. IF the parameter to
> > devm_gpiod_get_index() isn't intended to be used, why does it exist?
>
> Kerneldoc says:
>
> /**
> * gpiod_get_index - obtain a GPIO from a multi-index GPIO function
> * @dev:GPIO consumer, can be NULL for system-global GPIOs
> * @con_id: function within the GPIO consumer
> * @idx:index of the GPIO to obtain in the consumer
> *
>
> Basically it is just exposing the fact that of_find_gpio() and
> acpi_find_gpio() both take a con_id as argument.
>
> If we drill into this, we find that it is used to conjure the arbitrary string
> before the gpios in the DT case, like:
>
> foo-gpios = <...>;
>
> As in tegra30-beaver.dts...
>
> sdhci@7800 {
> status = "okay";
> cd-gpios = < TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
> wp-gpios = < TEGRA_GPIO(T, 3) GPIO_ACTIVE_HIGH>;
> power-gpios = < TEGRA_GPIO(D, 7) GPIO_ACTIVE_HIGH>;
> bus-width = <4>;
> };
>
> Instead of passing the GPIOs as index 0,1,2 they are named and I do admit
> this has a nice "things are under control" aspect to it.
[Gross, Mark] FWIW I don't think this is as "under control" as you do. Those
names in the above sdhci example are derived from a specific SDHCI tegra spec
sheet or schematic. Those names likely come from the data sheet for the
controller. I would like SDHCI kernel drivers to work pretty much the same for
all compatible controllers. The set of compatible controllers have spec sheets
that use different naming conventions for their pins and thus a name space
pollution of the SDHCI enumeration ABI will be a problem.
>
> In the ACPI case the con_id is not used for anything.
>
> So it is basically there to satisfy the habit in some device tree bindings to
> name gpio arrays instead of just passing gpios = <...>; (The latter should be
> encouraged going forward.)
[Gross, Mark] This is in fact just an idiom of the ACPI ABI inherited from
writing linux drivers that work on systems with BIOS/FW developed for
MS-Windows. For the devices I work on we have a number of driver teams filing
bugs against the BIOS/FW to add named GPIO objects to device name spaces such
that they can directly query for the GPIO their driver needs and avoid assuming
the 3rd GPIO is the special one they need for whatever...
So if you have the luxury of being able to influence (file bugs against or
write) the platform enumeration ABI then with ACPI you can have a named gpio
today. Note: there is an expectation that the _PRP feature to go into the next
version of ACPI and that should enable a trivial 1-1 mapping (when _prp is used
by the ACPI platform) between the different platform enumeration API's (DT and
ACPI).
Still, from a platform enumeration ABI point of view I see the arbitrariness of
indexes not much worse than the arbitrary naming of pins off of spec sheets or
schematics. Given that the authors of those specs/layouts come up with a new
naming schemes every time they log into their workstations (especially for the
schematics). I do admit names are a little better but still have the scaling
issue WRT namespaces and arbitrary naming by HW engineers over time.
>
> As DT is ABI we need to keep this forever, and driver may need to look for
> foo-gpios=<> and gpios=<> alike for backward compatibility if we'd change it,
> sweet isn't it? :-)
>
> I don't quite like this, as it is adding stupid nonsens arguments for ACPI
> GPIO
> producers (which only take an index AFAICT), but it
RE: [PATCH 2/4] net: rfkill: gpio: remove gpio names
Please know that no one should not consider me an authority on ACPI at this
time. But, I have some comments / context / thoughts below.
Also I apologize in advance for any email formatting issues caused by replying
to this via my work exchange account / outlook client. Folks can use
mgr...@linux.intel.com to avoid outlook-isms from me in the future.
-Original Message-
From: Linus Walleij [mailto:linus.wall...@linaro.org]
Sent: Tuesday, February 25, 2014 1:14 AM
To: Stephen Warren; Alexandre Courbot; Grant Likely;
devicet...@vger.kernel.org
Cc: Chen-Yu Tsai; Heikki Krogerus; Johannes Berg; David S. Miller; Rhyland
Klein; linux-wireless; netdev; linux-kernel; Arnd Bergmann; Gross, Mark
Subject: Re: [PATCH 2/4] net: rfkill: gpio: remove gpio names
On Fri, Feb 21, 2014 at 6:35 AM, Stephen Warren
swar...@wwwdotorg.org wrote:
On 02/20/2014 06:55 PM, Chen-Yu Tsai wrote:
That's correct. However using con_id to pass this results in
different behavior across DT and ACPI. A better way is to export the
labeling function so consumers can set meaningful labels themselves.
But this code is the consumer of those GPIOs. IF the parameter to
devm_gpiod_get_index() isn't intended to be used, why does it exist?
Kerneldoc says:
/**
* gpiod_get_index - obtain a GPIO from a multi-index GPIO function
* @dev:GPIO consumer, can be NULL for system-global GPIOs
* @con_id: function within the GPIO consumer
* @idx:index of the GPIO to obtain in the consumer
*
Basically it is just exposing the fact that of_find_gpio() and
acpi_find_gpio() both take a con_id as argument.
If we drill into this, we find that it is used to conjure the arbitrary string
before the gpios in the DT case, like:
foo-gpios = ...;
As in tegra30-beaver.dts...
sdhci@7800 {
status = okay;
cd-gpios = gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW;
wp-gpios = gpio TEGRA_GPIO(T, 3) GPIO_ACTIVE_HIGH;
power-gpios = gpio TEGRA_GPIO(D, 7) GPIO_ACTIVE_HIGH;
bus-width = 4;
};
Instead of passing the GPIOs as index 0,1,2 they are named and I do admit
this has a nice things are under control aspect to it.
[Gross, Mark] FWIW I don't think this is as under control as you do. Those
names in the above sdhci example are derived from a specific SDHCI tegra spec
sheet or schematic. Those names likely come from the data sheet for the
controller. I would like SDHCI kernel drivers to work pretty much the same for
all compatible controllers. The set of compatible controllers have spec sheets
that use different naming conventions for their pins and thus a name space
pollution of the SDHCI enumeration ABI will be a problem.
In the ACPI case the con_id is not used for anything.
So it is basically there to satisfy the habit in some device tree bindings to
name gpio arrays instead of just passing gpios = ...; (The latter should be
encouraged going forward.)
[Gross, Mark] This is in fact just an idiom of the ACPI ABI inherited from
writing linux drivers that work on systems with BIOS/FW developed for
MS-Windows. For the devices I work on we have a number of driver teams filing
bugs against the BIOS/FW to add named GPIO objects to device name spaces such
that they can directly query for the GPIO their driver needs and avoid assuming
the 3rd GPIO is the special one they need for whatever...
So if you have the luxury of being able to influence (file bugs against or
write) the platform enumeration ABI then with ACPI you can have a named gpio
today. Note: there is an expectation that the _PRP feature to go into the next
version of ACPI and that should enable a trivial 1-1 mapping (when _prp is used
by the ACPI platform) between the different platform enumeration API's (DT and
ACPI).
Still, from a platform enumeration ABI point of view I see the arbitrariness of
indexes not much worse than the arbitrary naming of pins off of spec sheets or
schematics. Given that the authors of those specs/layouts come up with a new
naming schemes every time they log into their workstations (especially for the
schematics). I do admit names are a little better but still have the scaling
issue WRT namespaces and arbitrary naming by HW engineers over time.
As DT is ABI we need to keep this forever, and driver may need to look for
foo-gpios= and gpios= alike for backward compatibility if we'd change it,
sweet isn't it? :-)
I don't quite like this, as it is adding stupid nonsens arguments for ACPI
GPIO
producers (which only take an index AFAICT), but it is a first sacrifice on
the
altar of trying to mask the differences between DT and ACPI probe paths
about which I have mixed feelings.
[Gross, Mark] I don't have mixed feelings. I want to see converged probe paths
that can handle both ACPI and DT platform ABI's seamlessly so we can reuse
drivers across architectures effectively. I think the _PRP
RE: [PATCH v2] MODSIGN: do not send garbage to stderr when enabling modules signature
Sorry. I don't use my outlook email on LMKL stuff hardly ever because of this sort of thing. --mgross http://umgwiki.intel.com/wiki/?title=Kernel > -Original Message- > From: Rusty Russell [mailto:ru...@rustcorp.com.au] > Sent: Wednesday, April 10, 2013 12:29 AM > To: Gross, Mark; Cohen, David A; dhowe...@redhat.com > Cc: linux-kernel@vger.kernel.org > Subject: RE: [PATCH v2] MODSIGN: do not send garbage to stderr when enabling > modules signature > > "Gross, Mark" writes: > > Reviewed-by: mark gross > > Not sure that's a valid email address, so I added a space. > > Cheers, > Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] MODSIGN: do not send garbage to stderr when enabling modules signature
Sorry. I don't use my outlook email on LMKL stuff hardly ever because of this sort of thing. --mgross http://umgwiki.intel.com/wiki/?title=Kernel -Original Message- From: Rusty Russell [mailto:ru...@rustcorp.com.au] Sent: Wednesday, April 10, 2013 12:29 AM To: Gross, Mark; Cohen, David A; dhowe...@redhat.com Cc: linux-kernel@vger.kernel.org Subject: RE: [PATCH v2] MODSIGN: do not send garbage to stderr when enabling modules signature Gross, Mark mark.gr...@intel.com writes: Reviewed-by: mark grossmark.gr...@intel.com Not sure that's a valid email address, so I added a space. Cheers, Rusty. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] MODSIGN: do not send garbage to stderr when enabling modules signature
> -Original Message-
> From: Cohen, David A
> Sent: Tuesday, April 09, 2013 2:39 PM
> To: ru...@rustcorp.com.au; dhowe...@redhat.com
> Cc: linux-kernel@vger.kernel.org; Gross, Mark; Cohen, David A
> Subject: [PATCH v2] MODSIGN: do not send garbage to stderr when enabling
> modules signature
>
> openssl may send garbage to stderr when generating X.509 key pair for modules
> signature regardless there was an error or not. It makes more difficult to
> create
> scripts based on kernel error/warning messages.
>
> When compiling kernel with -jN (N > 1), all warning/error messages printed
> while
> openssl is generating key pair may get mixed dots and other symbols openssl
> sends to stderr. This patch makes sure openssl logs go to default stdout.
>
> Example of the garbages:
>
> crypto/anubis.c:581: warning: ‘inter’ is used uninitialized in this function
> Generating a 4096 bit RSA private key .
> drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘gen6_ggtt_insert_entries’:
> drivers/gpu/drm/i915/i915_gem_gtt.c:440: warning: ‘addr’ may be used
> uninitialized in this function
> .net/mac80211/tx.c: In function ‘ieee80211_subif_start_xmit’:
> net/mac80211/tx.c:1780: warning: ‘chanctx_conf’ may be used uninitialized in
> this function
> ..drivers/isdn/hardware/mISDN/hfcpci.c: In function ‘hfcpci_softirq’:
> .drivers/isdn/hardware/mISDN/hfcpci.c:2298: warning: ignoring return value
> of ‘driver_for_each_device’, declared with attribute warn_unused_result
> net/unix/af_unix.c: In function ‘unix_bind’:
> net/unix/af_unix.c:892: warning: ‘path.dentry’ may be used uninitialized in
> this
> function
> net/unix/af_unix.c:892: warning: ‘path.mnt’ may be used uninitialized in this
> function ...++ In file included from drivers/message/i2o/config-osm.c:39:
> drivers/message/i2o/i2o_config.c: In function ‘i2o_cfg_passthru’:
> drivers/message/i2o/i2o_config.c:888: warning: cast to pointer from integer of
> different size
> drivers/message/i2o/i2o_config.c:943: warning: cast to pointer from integer of
> different size
> drivers/net/ethernet/amd/nmclan_cs.c: In function ‘nmclan_config’:
> drivers/net/ethernet/amd/nmclan_cs.c:625: warning:
> ‘pcmcia_request_exclusive_irq’ is deprecated (declared at
> include/pcmcia/ds.h:201)
> drivers/net/ethernet/mellanox/mlx4/mcg.c: In function ‘find_entry’:
> .
> ++
> writing new private key to 'signing_key.priv'
> -
> drivers/net/ethernet/mellanox/mlx4/mcg.c:601: warning: ‘hash’ may be used
> uninitialized in this function
>
> Signed-off-by: David Cohen
> ---
> kernel/Makefile |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/Makefile b/kernel/Makefile index bbde5f1..5a51e6c 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -175,7 +175,7 @@ signing_key.priv signing_key.x509: x509.genkey
> openssl req -new -nodes -utf8 -$(CONFIG_MODULE_SIG_HASH) -days
> 36500 \
> -batch -x509 -config x509.genkey \
> -outform DER -out signing_key.x509 \
> - -keyout signing_key.priv
> + -keyout signing_key.priv 2>&1
> @echo "###"
> @echo "### Key pair generated."
> @echo "###"
> --
> 1.7.10.4
Reviewed-by: mark gross
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH v2] MODSIGN: do not send garbage to stderr when enabling modules signature
-Original Message-
From: Cohen, David A
Sent: Tuesday, April 09, 2013 2:39 PM
To: ru...@rustcorp.com.au; dhowe...@redhat.com
Cc: linux-kernel@vger.kernel.org; Gross, Mark; Cohen, David A
Subject: [PATCH v2] MODSIGN: do not send garbage to stderr when enabling
modules signature
openssl may send garbage to stderr when generating X.509 key pair for modules
signature regardless there was an error or not. It makes more difficult to
create
scripts based on kernel error/warning messages.
When compiling kernel with -jN (N 1), all warning/error messages printed
while
openssl is generating key pair may get mixed dots and other symbols openssl
sends to stderr. This patch makes sure openssl logs go to default stdout.
Example of the garbages:
crypto/anubis.c:581: warning: ‘inter’ is used uninitialized in this function
Generating a 4096 bit RSA private key .
drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘gen6_ggtt_insert_entries’:
drivers/gpu/drm/i915/i915_gem_gtt.c:440: warning: ‘addr’ may be used
uninitialized in this function
.net/mac80211/tx.c: In function ‘ieee80211_subif_start_xmit’:
net/mac80211/tx.c:1780: warning: ‘chanctx_conf’ may be used uninitialized in
this function
..drivers/isdn/hardware/mISDN/hfcpci.c: In function ‘hfcpci_softirq’:
.drivers/isdn/hardware/mISDN/hfcpci.c:2298: warning: ignoring return value
of ‘driver_for_each_device’, declared with attribute warn_unused_result
net/unix/af_unix.c: In function ‘unix_bind’:
net/unix/af_unix.c:892: warning: ‘path.dentry’ may be used uninitialized in
this
function
net/unix/af_unix.c:892: warning: ‘path.mnt’ may be used uninitialized in this
function ...++ In file included from drivers/message/i2o/config-osm.c:39:
drivers/message/i2o/i2o_config.c: In function ‘i2o_cfg_passthru’:
drivers/message/i2o/i2o_config.c:888: warning: cast to pointer from integer of
different size
drivers/message/i2o/i2o_config.c:943: warning: cast to pointer from integer of
different size
drivers/net/ethernet/amd/nmclan_cs.c: In function ‘nmclan_config’:
drivers/net/ethernet/amd/nmclan_cs.c:625: warning:
‘pcmcia_request_exclusive_irq’ is deprecated (declared at
include/pcmcia/ds.h:201)
drivers/net/ethernet/mellanox/mlx4/mcg.c: In function ‘find_entry’:
.
++
writing new private key to 'signing_key.priv'
-
drivers/net/ethernet/mellanox/mlx4/mcg.c:601: warning: ‘hash’ may be used
uninitialized in this function
Signed-off-by: David Cohen david.a.co...@intel.com
---
kernel/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/Makefile b/kernel/Makefile index bbde5f1..5a51e6c 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -175,7 +175,7 @@ signing_key.priv signing_key.x509: x509.genkey
openssl req -new -nodes -utf8 -$(CONFIG_MODULE_SIG_HASH) -days
36500 \
-batch -x509 -config x509.genkey \
-outform DER -out signing_key.x509 \
- -keyout signing_key.priv
+ -keyout signing_key.priv 21
@echo ###
@echo ### Key pair generated.
@echo ###
--
1.7.10.4
Reviewed-by: mark grossmark.gr...@intel.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH RESEND] x86_dump_trace: avoiding endless " " is printed
Do you think we should add the same change to dumpstack_64.c too.
Looks like you addressed Alan's comments already (i.e. use of unlikely not
needed, us %p, and use pr_warn instead of printk)
--mark
> -Original Message-
> From: Liu, Chuansheng
> Sent: Sunday, August 26, 2012 6:56 PM
> To: 'linux-kernel@vger.kernel.org' (linux-kernel@vger.kernel.org)
> Cc: h...@linux.intel.com; Gross, Mark; a...@linux.intel.com
> Subject: [PATCH RESEND] x86_dump_trace: avoiding endless " " is
> printed
>
> From: liu chuansheng
> Subject: [PATCH] x86_dump_trace: avoiding endless " " is printed
>
> Found the case that endless " " printing in dump_trace, and no real
> meaningful stack traces are output, so there should be one rare case that
> possibly context->previous_esp = context or other cases.
>
> The endless " " is as below:
> ...
> [ 82.215244,0]
> [ 82.215399,0]
> [ 82.215554,0]
> [ 82.215710,0]
> [ 82.215865,0]
> [ 82.216022,0]
> [ 82.216178,0]
> [ 82.216333,0]
> [ 82.216488,0]
> [ 82.216643,0]
> [ 82.216798,0]
> [ 82.216953,0]
> ...
>
> This patch aim is:
> 1/ Limiting the " " outputing, currently the max IRQ contexts is
> 2(softirq+harirq combination); 2/ When the max IRQ contexts 2 is reached,
> print the context content to confirm;
>
> Change-Id: I6d72aa71c4c5ff8f9e6ae133b3f6bfec8887750d
> Signed-off-by: liu chuansheng
> ---
> arch/x86/kernel/dumpstack_32.c | 11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/dumpstack_32.c
> b/arch/x86/kernel/dumpstack_32.c index 1038a41..410fa38 100644
> --- a/arch/x86/kernel/dumpstack_32.c
> +++ b/arch/x86/kernel/dumpstack_32.c
> @@ -22,6 +22,7 @@ void dump_trace(struct task_struct *task, struct pt_regs
> *regs,
> const struct stacktrace_ops *ops, void *data) {
> int graph = 0;
> + int dump_irq_count = 0;
>
> if (!task)
> task = current;
> @@ -47,8 +48,18 @@ void dump_trace(struct task_struct *task, struct
> pt_regs *regs,
> stack = (unsigned long *)context->previous_esp;
> if (!stack)
> break;
> +
> + if (dump_irq_count > 2) {
> + pr_warn("break multi-IRQ print,"
> + "context=%p, stack=%p\n",
> + context,
> + stack);
> + break;
> + }
> +
> if (ops->stack(data, "IRQ") < 0)
> break;
> + dump_irq_count++;
> touch_nmi_watchdog();
> }
> }
> --
> 1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RESEND] x86_dump_trace: avoiding endless IRQ is printed
Do you think we should add the same change to dumpstack_64.c too.
Looks like you addressed Alan's comments already (i.e. use of unlikely not
needed, us %p, and use pr_warn instead of printk)
--mark
-Original Message-
From: Liu, Chuansheng
Sent: Sunday, August 26, 2012 6:56 PM
To: 'linux-kernel@vger.kernel.org' (linux-kernel@vger.kernel.org)
Cc: h...@linux.intel.com; Gross, Mark; a...@linux.intel.com
Subject: [PATCH RESEND] x86_dump_trace: avoiding endless IRQ is
printed
From: liu chuansheng chuansheng@intel.com
Subject: [PATCH] x86_dump_trace: avoiding endless IRQ is printed
Found the case that endless IRQ printing in dump_trace, and no real
meaningful stack traces are output, so there should be one rare case that
possibly context-previous_esp = context or other cases.
The endless IRQ is as below:
...
[ 82.215244,0] IRQ
[ 82.215399,0] IRQ
[ 82.215554,0] IRQ
[ 82.215710,0] IRQ
[ 82.215865,0] IRQ
[ 82.216022,0] IRQ
[ 82.216178,0] IRQ
[ 82.216333,0] IRQ
[ 82.216488,0] IRQ
[ 82.216643,0] IRQ
[ 82.216798,0] IRQ
[ 82.216953,0] IRQ
...
This patch aim is:
1/ Limiting the IRQ outputing, currently the max IRQ contexts is
2(softirq+harirq combination); 2/ When the max IRQ contexts 2 is reached,
print the context content to confirm;
Change-Id: I6d72aa71c4c5ff8f9e6ae133b3f6bfec8887750d
Signed-off-by: liu chuansheng chuansheng@intel.com
---
arch/x86/kernel/dumpstack_32.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/dumpstack_32.c
b/arch/x86/kernel/dumpstack_32.c index 1038a41..410fa38 100644
--- a/arch/x86/kernel/dumpstack_32.c
+++ b/arch/x86/kernel/dumpstack_32.c
@@ -22,6 +22,7 @@ void dump_trace(struct task_struct *task, struct pt_regs
*regs,
const struct stacktrace_ops *ops, void *data) {
int graph = 0;
+ int dump_irq_count = 0;
if (!task)
task = current;
@@ -47,8 +48,18 @@ void dump_trace(struct task_struct *task, struct
pt_regs *regs,
stack = (unsigned long *)context-previous_esp;
if (!stack)
break;
+
+ if (dump_irq_count 2) {
+ pr_warn(break multi-IRQ print,
+ context=%p, stack=%p\n,
+ context,
+ stack);
+ break;
+ }
+
if (ops-stack(data, IRQ) 0)
break;
+ dump_irq_count++;
touch_nmi_watchdog();
}
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/6] drivers/char/tlclk.c: fix error return code
Acked-by
--mark
Ps sorry for the outlook munged reply.
-Original Message-
From: Julia Lawall [mailto:julia.law...@lip6.fr]
Sent: Sunday, August 05, 2012 2:53 AM
To: Gross, Mark
Cc: kernel-janit...@vger.kernel.org; Arnd Bergmann; Greg Kroah-Hartman;
linux-kernel@vger.kernel.org; Julia Lawall
Subject: [PATCH 5/6] drivers/char/tlclk.c: fix error return code
From: Julia Lawall
Convert a 0 error return code to a negative one, as returned elsewhere in the
function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@
identifier ret;
expression e,e1,e2,e3,e4,x;
@@
(
if (\(ret != 0\|ret < 0\) || ...) { ... return ...; }
|
ret = 0
)
... when != ret = e1
*x =
\(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
... when != x = e2
when != ret = e3
*if (x == NULL || ...)
{
... when != ret = e4
* return ret;
}
//
Signed-off-by: Julia Lawall
---
drivers/char/tlclk.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tlclk.c b/drivers/char/tlclk.c index ce29e7c..e95e0ab
100644
--- a/drivers/char/tlclk.c
+++ b/drivers/char/tlclk.c
@@ -784,8 +784,10 @@ static int __init tlclk_init(void)
}
tlclk_major = ret;
alarm_events = kzalloc( sizeof(struct tlclk_alarms), GFP_KERNEL);
- if (!alarm_events)
+ if (!alarm_events) {
+ ret = -ENOMEM;
goto out1;
+ }
/* Read telecom clock IRQ number (Set by BIOS) */
if (!request_region(TLCLK_BASE, 8, "telco_clock")) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/6] drivers/char/tlclk.c: fix error return code
Acked-by mark.gr...@intel.com
--mark
Ps sorry for the outlook munged reply.
-Original Message-
From: Julia Lawall [mailto:julia.law...@lip6.fr]
Sent: Sunday, August 05, 2012 2:53 AM
To: Gross, Mark
Cc: kernel-janit...@vger.kernel.org; Arnd Bergmann; Greg Kroah-Hartman;
linux-kernel@vger.kernel.org; Julia Lawall
Subject: [PATCH 5/6] drivers/char/tlclk.c: fix error return code
From: Julia Lawall ju...@diku.dk
Convert a 0 error return code to a negative one, as returned elsewhere in the
function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
identifier ret;
expression e,e1,e2,e3,e4,x;
@@
(
if (\(ret != 0\|ret 0\) || ...) { ... return ...; }
|
ret = 0
)
... when != ret = e1
*x =
\(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
... when != x = e2
when != ret = e3
*if (x == NULL || ...)
{
... when != ret = e4
* return ret;
}
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
drivers/char/tlclk.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tlclk.c b/drivers/char/tlclk.c index ce29e7c..e95e0ab
100644
--- a/drivers/char/tlclk.c
+++ b/drivers/char/tlclk.c
@@ -784,8 +784,10 @@ static int __init tlclk_init(void)
}
tlclk_major = ret;
alarm_events = kzalloc( sizeof(struct tlclk_alarms), GFP_KERNEL);
- if (!alarm_events)
+ if (!alarm_events) {
+ ret = -ENOMEM;
goto out1;
+ }
/* Read telecom clock IRQ number (Set by BIOS) */
if (!request_region(TLCLK_BASE, 8, telco_clock)) {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Message codes (Re: [Announce] Linux-tiny project revival)
>-Original Message- >From: Joe Perches [mailto:[EMAIL PROTECTED] >Sent: Friday, September 21, 2007 3:33 PM >To: Gross, Mark >Cc: Rob Landley; Oleg Verych; Alexey Dobriyan; Michael Opdenacker; linux- >[EMAIL PROTECTED]; CE Linux Developers List; linux kernel >Subject: RE: Message codes (Re: [Announce] Linux-tiny project revival) > >On Fri, 2007-09-21 at 15:12 -0700, Gross, Mark wrote: >> Use compiler tricks to remove ALL the static printk string from >> the kernel and replace the printk with something that outputs a >> decimal index followed by tuples, of zero to N, hex-strings on > >> I proposed a mechanism for keeping all the printk data and saving space >> buy doing some table based compressions that has the side effect of >> making the syslog not human readable. You proposed a mechanism for >> no-oping out complete log-levels. > >How about compiler tricks to compress the static printk strings? >These could be expanded at runtime to use as the format. You would have to hold the text table (compressed) in memory to do this at run time. That would still be pretty large hunk of memory. > >Timothy Miller suggested something similar awhile ago. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Message codes (Re: [Announce] Linux-tiny project revival)
>-Original Message- >From: Rob Landley [mailto:[EMAIL PROTECTED] >Sent: Friday, September 21, 2007 2:16 PM >To: Gross, Mark >Cc: Oleg Verych; Alexey Dobriyan; Michael Opdenacker; linux- >[EMAIL PROTECTED]; CE Linux Developers List; linux kernel >Subject: Re: Message codes (Re: [Announce] Linux-tiny project revival) > >On Friday 21 September 2007 9:18:40 am Gross, Mark wrote: >> >-Original Message- >> >From: Oleg Verych [mailto:[EMAIL PROTECTED] >> >Sent: Thursday, September 20, 2007 5:58 PM >> >To: Gross, Mark >> >Cc: Rob Landley; Alexey Dobriyan; Michael Opdenacker; linux- >> >[EMAIL PROTECTED]; CE Linux Developers List; linux kernel >> >Subject: Message codes (Re: [Announce] Linux-tiny project revival) >> > >> >* Thu, 20 Sep 2007 15:15:47 -0700 >> >* X-MimeOLE: Produced By Microsoft Exchange V6.5 >> >[] >> > >> >>>*Shrug*. >> >>> >> >>>My problem is that switching off printk is the single biggest bloat >> >> >> >> cutter >> >> >> >>>in >> >>>the kernel, yet it makes the resulting system very hard to support. >> >> It >> >> >>>combines a big upside with a big downside, and I'd like something in >> >>>between. >> >> >> >> What about getting even more hard core? >> >> >> >> Use compiler tricks to remove ALL the static printk string from the >> >> kernel and replace the printk with something that outputs an decimal >> >> index followed by tuples, of zero to N, hex-strings on a single line. >> > >> >Not all, but critical info, that must exist in human-readable form of >> >course. >> >> I disagree. For a production product the you want minimal information >> to reduce the communication bandwidth required between the remote >> customer and the support organization. >> >> In fact there is a good argument that you don't what the remote customer >> to know enough to start guessing. > >Don't use Linux then. Open source is a horrible fit for the way you think. I'll do what I like, thank you. I'll continue to use Linux, I think it's a fine fit for the way *I* think. > >I'm sympathetic to "shrink the binary size" arguments. I'm not really >sympathic to "keep the customer in the dark intentionally" arguments, >whether >the justification is "because they're stupid", "to increase dependency on >our >support staff", or any other reason. You are now talking religion at this point. Do you have a technical or even experience based point to make? I have experience that has shown that providing too much information in a production product can is confusing, harmful and costly when dealing with consumers. Your opinions won't change that. I proposed a mechanism for keeping all the printk data and saving space buy doing some table based compressions that has the side effect of making the syslog not human readable. You proposed a mechanism for no-oping out complete log-levels. Which way hides more from the user? No-oping the log-levels is the easier to implement. > >> >Seriously. When in the Windows there are only messages like: >> > >> >"Error (Code:0x2012)". >> >> Now it's been ~8 years since I did any serious windows work, but if I >> recall correctly ALL THE FRICKING TIME!!! When was the last time you've >> seen a bug check on windows? This is about all you get. > >I believe he was holding it up as a bad example, and definitely not >something >we want to emulate. There is a time and place for many things. Even error codes. --mgross - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Message codes (Re: [Announce] Linux-tiny project revival)
>-Original Message- >From: Oleg Verych [mailto:[EMAIL PROTECTED] >Sent: Thursday, September 20, 2007 5:58 PM >To: Gross, Mark >Cc: Rob Landley; Alexey Dobriyan; Michael Opdenacker; linux- >[EMAIL PROTECTED]; CE Linux Developers List; linux kernel >Subject: Message codes (Re: [Announce] Linux-tiny project revival) > >* Thu, 20 Sep 2007 15:15:47 -0700 >* X-MimeOLE: Produced By Microsoft Exchange V6.5 >[] >>>*Shrug*. >>> >>>My problem is that switching off printk is the single biggest bloat >> cutter >>>in >>>the kernel, yet it makes the resulting system very hard to support. It >>>combines a big upside with a big downside, and I'd like something in >>>between. >> >> What about getting even more hard core? >> >> Use compiler tricks to remove ALL the static printk string from the >> kernel and replace the printk with something that outputs an decimal >> index followed by tuples, of zero to N, hex-strings on a single line. > >Not all, but critical info, that must exist in human-readable form of >course. I disagree. For a production product the you want minimal information to reduce the communication bandwidth required between the remote customer and the support organization. In fact there is a good argument that you don't what the remote customer to know enough to start guessing. In the support stage of a products life cycle you really don't want guessing or fudging of information based on guessing. Keeping the output cryptic and short will avoid these things. (That really does happen and it cost a lot in support engineering time) > >> Then have the syslogd or some other utility take this cryptic output and >> convolve it with a table (created at compile time) to re-create what >> would have been dumped to the sys-log ring buffer. This way you strip >> out most of the static text from the kernel and yet can still re-create >> the kernlog output. >> >> At least as a post processing operation > >Sure, but a little problem is, that many kernel developers do C (mostly) >and Perl (occasionally), i.e. very few do non-trivial userspace (even >userspace do too much C and Perl sometimes [: ><http://thread.gmane.org/gmane.comp.lib.glibc.alpha/12739>) > Oh poo. Kernel programmers can use user mode tools and write them too, and I *know* even I could write such a post processing program to take a somewhat compressed and cryptic output and generate what would have been created in the syslog used. (in python) >> Is this an old idea? I'm guessing this has been at least proposed >> before > >Seriously. When in the Windows there are only messages like: > >"Error (Code:0x2012)". Now it's been ~8 years since I did any serious windows work, but if I recall correctly ALL THE FRICKING TIME!!! When was the last time you've seen a bug check on windows? This is about all you get. > >In the Linux... well, embedded targets, this can be turned in a very >efficient thing by means of userspace. On other setups this can be nice >and pleasant one, with yet another L10N project, recently promoted by >README translations. But,,, see problem above. > >From you comments I'm not sure you are for or against this idea. --mgross - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Message codes (Re: [Announce] Linux-tiny project revival)
-Original Message- From: Oleg Verych [mailto:[EMAIL PROTECTED] Sent: Thursday, September 20, 2007 5:58 PM To: Gross, Mark Cc: Rob Landley; Alexey Dobriyan; Michael Opdenacker; linux- [EMAIL PROTECTED]; CE Linux Developers List; linux kernel Subject: Message codes (Re: [Announce] Linux-tiny project revival) * Thu, 20 Sep 2007 15:15:47 -0700 * X-MimeOLE: Produced By Microsoft Exchange V6.5 [] *Shrug*. My problem is that switching off printk is the single biggest bloat cutter in the kernel, yet it makes the resulting system very hard to support. It combines a big upside with a big downside, and I'd like something in between. What about getting even more hard core? Use compiler tricks to remove ALL the static printk string from the kernel and replace the printk with something that outputs an decimal index followed by tuples, of zero to N, hex-strings on a single line. Not all, but critical info, that must exist in human-readable form of course. I disagree. For a production product the you want minimal information to reduce the communication bandwidth required between the remote customer and the support organization. In fact there is a good argument that you don't what the remote customer to know enough to start guessing. In the support stage of a products life cycle you really don't want guessing or fudging of information based on guessing. Keeping the output cryptic and short will avoid these things. (That really does happen and it cost a lot in support engineering time) Then have the syslogd or some other utility take this cryptic output and convolve it with a table (created at compile time) to re-create what would have been dumped to the sys-log ring buffer. This way you strip out most of the static text from the kernel and yet can still re-create the kernlog output. At least as a post processing operation Sure, but a little problem is, that many kernel developers do C (mostly) and Perl (occasionally), i.e. very few do non-trivial userspace (even userspace do too much C and Perl sometimes [: http://thread.gmane.org/gmane.comp.lib.glibc.alpha/12739) Oh poo. Kernel programmers can use user mode tools and write them too, and I *know* even I could write such a post processing program to take a somewhat compressed and cryptic output and generate what would have been created in the syslog used. (in python) Is this an old idea? I'm guessing this has been at least proposed before Seriously. When in the Windows there are only messages like: Error (Code:0x2012). Now it's been ~8 years since I did any serious windows work, but if I recall correctly ALL THE FRICKING TIME!!! When was the last time you've seen a bug check on windows? This is about all you get. In the Linux... well, embedded targets, this can be turned in a very efficient thing by means of userspace. On other setups this can be nice and pleasant one, with yet another L10N project, recently promoted by README translations. But,,, see problem above. From you comments I'm not sure you are for or against this idea. --mgross - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Message codes (Re: [Announce] Linux-tiny project revival)
-Original Message- From: Rob Landley [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 2:16 PM To: Gross, Mark Cc: Oleg Verych; Alexey Dobriyan; Michael Opdenacker; linux- [EMAIL PROTECTED]; CE Linux Developers List; linux kernel Subject: Re: Message codes (Re: [Announce] Linux-tiny project revival) On Friday 21 September 2007 9:18:40 am Gross, Mark wrote: -Original Message- From: Oleg Verych [mailto:[EMAIL PROTECTED] Sent: Thursday, September 20, 2007 5:58 PM To: Gross, Mark Cc: Rob Landley; Alexey Dobriyan; Michael Opdenacker; linux- [EMAIL PROTECTED]; CE Linux Developers List; linux kernel Subject: Message codes (Re: [Announce] Linux-tiny project revival) * Thu, 20 Sep 2007 15:15:47 -0700 * X-MimeOLE: Produced By Microsoft Exchange V6.5 [] *Shrug*. My problem is that switching off printk is the single biggest bloat cutter in the kernel, yet it makes the resulting system very hard to support. It combines a big upside with a big downside, and I'd like something in between. What about getting even more hard core? Use compiler tricks to remove ALL the static printk string from the kernel and replace the printk with something that outputs an decimal index followed by tuples, of zero to N, hex-strings on a single line. Not all, but critical info, that must exist in human-readable form of course. I disagree. For a production product the you want minimal information to reduce the communication bandwidth required between the remote customer and the support organization. In fact there is a good argument that you don't what the remote customer to know enough to start guessing. Don't use Linux then. Open source is a horrible fit for the way you think. I'll do what I like, thank you. I'll continue to use Linux, I think it's a fine fit for the way *I* think. I'm sympathetic to shrink the binary size arguments. I'm not really sympathic to keep the customer in the dark intentionally arguments, whether the justification is because they're stupid, to increase dependency on our support staff, or any other reason. You are now talking religion at this point. Do you have a technical or even experience based point to make? I have experience that has shown that providing too much information in a production product can is confusing, harmful and costly when dealing with consumers. Your opinions won't change that. I proposed a mechanism for keeping all the printk data and saving space buy doing some table based compressions that has the side effect of making the syslog not human readable. You proposed a mechanism for no-oping out complete log-levels. Which way hides more from the user? No-oping the log-levels is the easier to implement. Seriously. When in the Windows there are only messages like: Error (Code:0x2012). Now it's been ~8 years since I did any serious windows work, but if I recall correctly ALL THE FRICKING TIME!!! When was the last time you've seen a bug check on windows? This is about all you get. I believe he was holding it up as a bad example, and definitely not something we want to emulate. There is a time and place for many things. Even error codes. --mgross - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Message codes (Re: [Announce] Linux-tiny project revival)
-Original Message- From: Joe Perches [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 3:33 PM To: Gross, Mark Cc: Rob Landley; Oleg Verych; Alexey Dobriyan; Michael Opdenacker; linux- [EMAIL PROTECTED]; CE Linux Developers List; linux kernel Subject: RE: Message codes (Re: [Announce] Linux-tiny project revival) On Fri, 2007-09-21 at 15:12 -0700, Gross, Mark wrote: Use compiler tricks to remove ALL the static printk string from the kernel and replace the printk with something that outputs a decimal index followed by tuples, of zero to N, hex-strings on I proposed a mechanism for keeping all the printk data and saving space buy doing some table based compressions that has the side effect of making the syslog not human readable. You proposed a mechanism for no-oping out complete log-levels. How about compiler tricks to compress the static printk strings? These could be expanded at runtime to use as the format. You would have to hold the text table (compressed) in memory to do this at run time. That would still be pretty large hunk of memory. Timothy Miller suggested something similar awhile ago. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [Celinux-dev] Re: [Announce] Linux-tiny project revival
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:celinux-dev-
>[EMAIL PROTECTED] On Behalf Of Rob Landley
>Sent: Thursday, September 20, 2007 3:02 PM
>To: Alexey Dobriyan
>Cc: Michael Opdenacker; [EMAIL PROTECTED]; CE Linux Developers
List;
>linux kernel
>Subject: [Celinux-dev] Re: [Announce] Linux-tiny project revival
>
>On Thursday 20 September 2007 2:58:44 pm Alexey Dobriyan wrote:
>> On Thu, Sep 20, 2007 at 03:38:42PM -0500, Rob Landley wrote:
>> > I've been playing with an idea for a while to improve the printk()
>> > situation, but it's a more intrusive change than I've had time to
bang
>> > on.
>> >
>> > Right now, the first argument to printk() is a loglevel, but it's
>handled
>> > via string concatenation. I'd like to change that to be an
integer,
>and
>> > make it an actual comma-separated first argument. (Mandatory, not
>> > optional.)
>> >
>> > So instead of:
>> > printk(KERN_NOTICE "Fruit=%d\n", banana);
>> > It would now be:
>> > printk(KERN_NOTICE, "Fruit=%d\n", banana);
>> >
>> > Change the header from:
>> > #define KERN_NOTICE "<5>"
>> > to:
>> > #define KERN_NOTICE 5
>> >
>> > Then you can change the printk guts to do something vaguely like
>> > (untested): #define printk(arg1, arg2, ...) actual_printk("<" #arg1
">"
>> > arg2, __VA_ARGS__)
>> >
>> > And so far no behavior has changed. But now the _fun_ part is, you
can
>> > add a config symbol for "what is the minimum loglevel I care
about?"
>>
>> Given that
>> a) there're plenty of printks without any KERN_* bloat,
>
>> b) there're printks that SHOULD NOT have KERN_* bloat,
>
>So define a level 0 that doesn't prepend any level to the string, and
have
>the
>macro filter that out at the same default level it counts as now.
>(KERN_INFO, I think?) The tests are all on contants which should
resolve
>at
>compile time and the dead code eliminator should zap it, even if the
macro
>gets more complicated it shouldn't result in a bigger binary.
>
>> c) debugging-by-printk method is widely used and this will force
>>additional typing, head-scratching and swear words
>
>Because we never change kernel internal APIs. Oh yeah. Never happens.
>
>> d) time wasted on pointless discussions whether some particular
>>printk ALERT or CRIT
>
>Let me get this straight: you're objecting to actually making the
printk
>levels useful enough that developers start to care what they're set to,
>because then they might be motivated to want some of them changed?
>
>Make it useful, people might care, thus they might talk about it...
>
>Sorry, I'm still missing the downside here.
>
>> e) flag day for printk,
>
>That's the main reason I haven't played with it so far, although it
would
>be
>easy to define a new symbol (dprintk or some such, although I note
several
>drivers are already using that) and transition gradually.
>
>> I think that this idea is not worth it.
>
>*Shrug*.
>
>My problem is that switching off printk is the single biggest bloat
cutter
>in
>the kernel, yet it makes the resulting system very hard to support. It
>combines a big upside with a big downside, and I'd like something in
>between.
What about getting even more hard core?
Use compiler tricks to remove ALL the static printk string from the
kernel and replace the printk with something that outputs an decimal
index followed by tuples, of zero to N, hex-strings on a single line.
Then have the syslogd or some other utility take this cryptic output and
convolve it with a table (created at compile time) to re-create what
would have been dumped to the sys-log ring buffer. This way you strip
out most of the static text from the kernel and yet can still re-create
the kernlog output.
At least as a post processing operation
Is this an old idea? I'm guessing this has been at least proposed
before
--mgross
the
>
>> > #define printk(level, str, ...) \
>> > do { \
>> > if (level < CONFIG_PRINTK_DOICARE) \
>> > actual_printk("<" #level ">" str, __VA_ARGS__); \
>> > } while(0);
>> >
>> > Opinions?
>>
>> Ick.
>>
>> Alexey "ignore_loglevel" Dobriyan
>
>But ignore_loglevel doesn't decrease the size of the _binary_. That's
what
>we're talking about here with the -tiny tree. Embedded developers want
to
>squeeze more code onto smaller flash/rom chips. Setting
ignore_loglevel
>does
>prevent these messages from ever being emitted, but they're still in
the
>kernel image as dead weight. It saves noise but doesn't save _space_.
>
>I'm proposing allowing an ignore_loglevel to remove the unused messages
at
>compile time so they don't take up space. Doing that requires the
levels
>to
>be integers so they can be compared with < or >, and the remaining
changes
>follow logically. (To me, anyway...)
>
>Rob
>--
>"One of my most productive days was throwing away 1000 lines of code."
> - Ken Thompson.
>___
>Celinux-dev mailing list
>[EMAIL PROTECTED]
>http://tree.celinuxforum.org/mailman/listinfo/celinux-dev
-
To
RE: [Celinux-dev] Re: [Announce] Linux-tiny project revival
-Original Message-
From: [EMAIL PROTECTED] [mailto:celinux-dev-
[EMAIL PROTECTED] On Behalf Of Rob Landley
Sent: Thursday, September 20, 2007 3:02 PM
To: Alexey Dobriyan
Cc: Michael Opdenacker; [EMAIL PROTECTED]; CE Linux Developers
List;
linux kernel
Subject: [Celinux-dev] Re: [Announce] Linux-tiny project revival
On Thursday 20 September 2007 2:58:44 pm Alexey Dobriyan wrote:
On Thu, Sep 20, 2007 at 03:38:42PM -0500, Rob Landley wrote:
I've been playing with an idea for a while to improve the printk()
situation, but it's a more intrusive change than I've had time to
bang
on.
Right now, the first argument to printk() is a loglevel, but it's
handled
via string concatenation. I'd like to change that to be an
integer,
and
make it an actual comma-separated first argument. (Mandatory, not
optional.)
So instead of:
printk(KERN_NOTICE Fruit=%d\n, banana);
It would now be:
printk(KERN_NOTICE, Fruit=%d\n, banana);
Change the header from:
#define KERN_NOTICE 5
to:
#define KERN_NOTICE 5
Then you can change the printk guts to do something vaguely like
(untested): #define printk(arg1, arg2, ...) actual_printk( #arg1
arg2, __VA_ARGS__)
And so far no behavior has changed. But now the _fun_ part is, you
can
add a config symbol for what is the minimum loglevel I care
about?
Given that
a) there're plenty of printks without any KERN_* bloat,
b) there're printks that SHOULD NOT have KERN_* bloat,
So define a level 0 that doesn't prepend any level to the string, and
have
the
macro filter that out at the same default level it counts as now.
(KERN_INFO, I think?) The tests are all on contants which should
resolve
at
compile time and the dead code eliminator should zap it, even if the
macro
gets more complicated it shouldn't result in a bigger binary.
c) debugging-by-printk method is widely used and this will force
additional typing, head-scratching and swear words
Because we never change kernel internal APIs. Oh yeah. Never happens.
d) time wasted on pointless discussions whether some particular
printk ALERT or CRIT
Let me get this straight: you're objecting to actually making the
printk
levels useful enough that developers start to care what they're set to,
because then they might be motivated to want some of them changed?
Make it useful, people might care, thus they might talk about it...
Sorry, I'm still missing the downside here.
e) flag day for printk,
That's the main reason I haven't played with it so far, although it
would
be
easy to define a new symbol (dprintk or some such, although I note
several
drivers are already using that) and transition gradually.
I think that this idea is not worth it.
*Shrug*.
My problem is that switching off printk is the single biggest bloat
cutter
in
the kernel, yet it makes the resulting system very hard to support. It
combines a big upside with a big downside, and I'd like something in
between.
What about getting even more hard core?
Use compiler tricks to remove ALL the static printk string from the
kernel and replace the printk with something that outputs an decimal
index followed by tuples, of zero to N, hex-strings on a single line.
Then have the syslogd or some other utility take this cryptic output and
convolve it with a table (created at compile time) to re-create what
would have been dumped to the sys-log ring buffer. This way you strip
out most of the static text from the kernel and yet can still re-create
the kernlog output.
At least as a post processing operation
Is this an old idea? I'm guessing this has been at least proposed
before
--mgross
the
#define printk(level, str, ...) \
do { \
if (level CONFIG_PRINTK_DOICARE) \
actual_printk( #level str, __VA_ARGS__); \
} while(0);
Opinions?
Ick.
Alexey ignore_loglevel Dobriyan
But ignore_loglevel doesn't decrease the size of the _binary_. That's
what
we're talking about here with the -tiny tree. Embedded developers want
to
squeeze more code onto smaller flash/rom chips. Setting
ignore_loglevel
does
prevent these messages from ever being emitted, but they're still in
the
kernel image as dead weight. It saves noise but doesn't save _space_.
I'm proposing allowing an ignore_loglevel to remove the unused messages
at
compile time so they don't take up space. Doing that requires the
levels
to
be integers so they can be compared with or , and the remaining
changes
follow logically. (To me, anyway...)
Rob
--
One of my most productive days was throwing away 1000 lines of code.
- Ken Thompson.
___
Celinux-dev mailing list
[EMAIL PROTECTED]
http://tree.celinuxforum.org/mailman/listinfo/celinux-dev
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
