Re: [PATCH v6 6/7] dt: thermal: tsens: Document the fallback DT property for v2 of TSENS IP
On Thu, Jul 12, 2018 at 12:12 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria
> wrote:
> > We want to create common code for v2 of the TSENS IP block that is used in
> > a large number of Qualcomm SoCs. "qcom,tsens-v2" should be able to handle
> > most of the common functionality start with a common get_temp() function.
> >
> > It is also necessary to split out the memory regions for the TM and SROT
> > register banks because their offsets are not constant across SoC families.
>
> nit that bindings should be earlier in the patch series than the code
> implementing the bindings.
Will reorder.
>
> > Signed-off-by: Amit Kucheria
> > ---
> > .../devicetree/bindings/thermal/qcom-tsens.txt | 25
> > +-
> > 1 file changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> > b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> > index 06195e8..8f963b1 100644
> > --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> > +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> > @@ -1,10 +1,16 @@
> > * QCOM SoC Temperature Sensor (TSENS)
> >
> > Required properties:
> > -- compatible :
> > - - "qcom,msm8916-tsens" : For 8916 Family of SoCs
> > - - "qcom,msm8974-tsens" : For 8974 Family of SoCs
> > - - "qcom,msm8996-tsens" : For 8996 Family of SoCs
> > +- compatible:
> > + Must be one of the following:
> > +- "qcom,msm8916-tsens" (MSM8916)
> > +- "qcom,msm8974-tsens" (MSM8974)
> > +- "qcom,msm8996-tsens" (MSM8996)
> > +- "qcom,msm8998-tsens", "qcom,tsens-v2" (MSM8998)
> > +- "qcom,sdm845-tsens", "qcom,tsens-v2" (SDM845)
> > + The generic "qcom,tsens-v2" property must be used as a fallback for any
> > SoC with
> > + version 2 of the TSENS IP. MSM8996 is the only exception beacause the
> > generic
> > + property did not exist when support was added.
> >
> > - reg: Address range of the thermal registers
>
> You need to document that for old SoCs where TM / SROT were 0x1000
> apart (SROT first) that one "reg" field was OK. ...and that for new
> SoCs you specify two reg ranges: the first for TM and the second for
> SROT.
OK.
> > - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
> > @@ -12,7 +18,7 @@ Required properties:
> > - Refer to Documentation/devicetree/bindings/nvmem/nvmem.txt to know how
> > to specify
> > nvmem cells
> >
> > -Example:
> > +Example 1 (legacy support before a fallback tsens-v2 propoerty was
> > introduced):
> > tsens: thermal-sensor@90 {
> > compatible = "qcom,msm8916-tsens";
> > reg = <0x4a8000 0x2000>;
> > @@ -20,3 +26,12 @@ tsens: thermal-sensor@90 {
> > nvmem-cell-names = "caldata", "calsel";
> > #thermal-sensor-cells = <1>;
> > };
> > +
> > +Example 2 (for any platform containing v2 of the TSENS IP):
> > +tsens0: tsens@c222000 {
>
> A) Use a generic name for the node, not a specific one. Thus the node
> should be "thermal-sensor", not "tsens".
>
> B) This unit address needs to match the _first_ reg address listed.
> Give your reg below, this should be @c263000
>
> Thus your node name should be:
>
> tsens0: thermal-sensor@c263000 {
Fixed
> > + compatible = "qcom,sdm845-tsens", "qcom,tsens-v2";
> > + reg = <0xc263000 0x1ff>, /* TM */
> > + <0xc222000 0x1ff>; /* SROT */
> > + #qcom,sensors = <13>;
>
> The "#qcom,sensors" property seems wrong in a few ways:
>
> A) I wouldn't have expected it to start with a "#". I only expect to
> see that on things specifying sizes / lengths. Rob can feel free to
> override me, though.
>
> B) It's not documented above. Just putting something in an example
> doesn't document it--it needs to be listed in the "Optional
> properties".
Re: [PATCH] cnic: use kvzalloc to allocate memory for csk_tbl
From: Jan Dakinevich Date: Mon, 9 Jul 2018 16:51:19 +0300 > Size of csk_tbl is about 58K, which means 3rd order page allocation. > kvzalloc provides a fallback if no high order memory is available. > > Signed-off-by: Jan Dakinevich Applied, thanks.
Re: [PATCH v6 6/7] dt: thermal: tsens: Document the fallback DT property for v2 of TSENS IP
On Thu, Jul 12, 2018 at 12:12 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria
> wrote:
> > We want to create common code for v2 of the TSENS IP block that is used in
> > a large number of Qualcomm SoCs. "qcom,tsens-v2" should be able to handle
> > most of the common functionality start with a common get_temp() function.
> >
> > It is also necessary to split out the memory regions for the TM and SROT
> > register banks because their offsets are not constant across SoC families.
>
> nit that bindings should be earlier in the patch series than the code
> implementing the bindings.
Will reorder.
>
> > Signed-off-by: Amit Kucheria
> > ---
> > .../devicetree/bindings/thermal/qcom-tsens.txt | 25
> > +-
> > 1 file changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> > b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> > index 06195e8..8f963b1 100644
> > --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> > +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> > @@ -1,10 +1,16 @@
> > * QCOM SoC Temperature Sensor (TSENS)
> >
> > Required properties:
> > -- compatible :
> > - - "qcom,msm8916-tsens" : For 8916 Family of SoCs
> > - - "qcom,msm8974-tsens" : For 8974 Family of SoCs
> > - - "qcom,msm8996-tsens" : For 8996 Family of SoCs
> > +- compatible:
> > + Must be one of the following:
> > +- "qcom,msm8916-tsens" (MSM8916)
> > +- "qcom,msm8974-tsens" (MSM8974)
> > +- "qcom,msm8996-tsens" (MSM8996)
> > +- "qcom,msm8998-tsens", "qcom,tsens-v2" (MSM8998)
> > +- "qcom,sdm845-tsens", "qcom,tsens-v2" (SDM845)
> > + The generic "qcom,tsens-v2" property must be used as a fallback for any
> > SoC with
> > + version 2 of the TSENS IP. MSM8996 is the only exception beacause the
> > generic
> > + property did not exist when support was added.
> >
> > - reg: Address range of the thermal registers
>
> You need to document that for old SoCs where TM / SROT were 0x1000
> apart (SROT first) that one "reg" field was OK. ...and that for new
> SoCs you specify two reg ranges: the first for TM and the second for
> SROT.
OK.
> > - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
> > @@ -12,7 +18,7 @@ Required properties:
> > - Refer to Documentation/devicetree/bindings/nvmem/nvmem.txt to know how
> > to specify
> > nvmem cells
> >
> > -Example:
> > +Example 1 (legacy support before a fallback tsens-v2 propoerty was
> > introduced):
> > tsens: thermal-sensor@90 {
> > compatible = "qcom,msm8916-tsens";
> > reg = <0x4a8000 0x2000>;
> > @@ -20,3 +26,12 @@ tsens: thermal-sensor@90 {
> > nvmem-cell-names = "caldata", "calsel";
> > #thermal-sensor-cells = <1>;
> > };
> > +
> > +Example 2 (for any platform containing v2 of the TSENS IP):
> > +tsens0: tsens@c222000 {
>
> A) Use a generic name for the node, not a specific one. Thus the node
> should be "thermal-sensor", not "tsens".
>
> B) This unit address needs to match the _first_ reg address listed.
> Give your reg below, this should be @c263000
>
> Thus your node name should be:
>
> tsens0: thermal-sensor@c263000 {
Fixed
> > + compatible = "qcom,sdm845-tsens", "qcom,tsens-v2";
> > + reg = <0xc263000 0x1ff>, /* TM */
> > + <0xc222000 0x1ff>; /* SROT */
> > + #qcom,sensors = <13>;
>
> The "#qcom,sensors" property seems wrong in a few ways:
>
> A) I wouldn't have expected it to start with a "#". I only expect to
> see that on things specifying sizes / lengths. Rob can feel free to
> override me, though.
>
> B) It's not documented above. Just putting something in an example
> doesn't document it--it needs to be listed in the "Optional
> properties".
Re: [PATCH] cnic: use kvzalloc to allocate memory for csk_tbl
From: Jan Dakinevich Date: Mon, 9 Jul 2018 16:51:19 +0300 > Size of csk_tbl is about 58K, which means 3rd order page allocation. > kvzalloc provides a fallback if no high order memory is available. > > Signed-off-by: Jan Dakinevich Applied, thanks.
Re: linux-next: duplicate patches in the gfs2 and xfs trees
On Thu, Jul 12, 2018 at 07:16:18AM +0200, Andreas Gruenbacher wrote:
> Hi Stephen,
>
> On 12 July 2018 at 06:41, Stephen Rothwell wrote:
> > Hi Andreas,
> >
> > On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher
> > wrote:
> >>
> >> this is what I'm seeing (git log --pretty=oneline --abbrev-commit
> >> --graph ^origin/master gfs2/for-next):
> >>
> >> * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize
> >> == PAGE_SIZE
> >> * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads
> >> * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next
> >> |\
> >> | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support
> >> to iomap_readpage_actor
> >> | * ec181f6782d8 iomap: support direct I/O to inline data
> >> | * 09230435dffd iomap: refactor iomap_dio_actor
> >> | * c03cea42149d iomap: add initial support for writes without buffer heads
> >> | * 72b4daa24129 iomap: add an iomap-based readpage and readpages
> >> implementation
> >> * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap
> >> * | 2e2834ef1797 GFS2: Fix recovery issues for spectators
> >> * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next
> >> |\ \
> >> | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end}
> >> | * | 967bcc91b044 gfs2: iomap direct I/O support
> >> | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup
> >> | * | 64bc06bb32ee gfs2: iomap buffered write support
> >> | * | d505a96a3b16 gfs2: Further iomap cleanups
> >> | |/
> >> | * e184fde6f3f5 iomap: add private pointer to struct iomap
> >> | * 63899c6f8851 iomap: add a page_done callback
> >> | * 19e0c58f6552 iomap: generic inline data handling
> >> | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously
> >> | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new
> >> | * a6d639da63ae fs: factor out a __generic_write_end helper
> >> * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t
> >> * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of
> >> posix_acl_to_xattr
> >> * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have
> >> blocks reserved
> >> * d1475c07f7ce GFS2: rgrp free blocks used incorrectly
> >> * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd
> >> * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code
> >> * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly
> >> * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole
> >> * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock
> >> * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes
> >>
> >> Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on
> >> xfs/iomap-4.19-merge. That was my initial merge from
> >> xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge
> >> commit. I've then merged our iomap-write branch into for-next, with
> >> two additional commits on top. Then comes the rest of
> >> xfs/iomap-4.19-merge (that branch has moved ahead in the meantime),
> >> again with two more commits on top.
> >>
> >> There are no rebased commits, you're looking at the exact same commits.
> >
> > The problem is that commits
> >
> > a6d639da63ae fs: factor out a __generic_write_end helper
> >
> > to
> >
> > 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support
> >
> > have been rebased in the xfs tree from a base of v4.18-rc1 to
> > v4.18-rc4, so that those patches now appear twice in linux-next where I
> > have merged the gfs2 tree and the xfs tree.
>
> Ah, I see now. It's xfs/for-next that contains those rebased commits
> from xfs/iomap-4.19-merge.
>
> > This has caused a few
> > conflicts today as there are more changes to the same files affected by
> > those commits in the xfs tree. to iomap_readpage_actor
> >
> > What should have happened is that those commits should not have been
> > rebased, so either the xfs tree needs rebuilding to use the old
> > commits, or your tree needs to be rebuilt using the new commits from
> > the xfs tree. This is why we do not like the rebasing of published
> > trees (especially when a subset of the tree is shared with other
> > developers).
> >
> > Also, if you are going to merge (part of) another tree you need to make
> > sure that the other maintainer will not do a rebase of it (I assume
> > that this was probably talked about).
>
> Indeed, the idea of setting up xfs/iomap-4.19-merge was to have a
> common base that xfs/for-next and gfs2/for-next could both merge from.
> Darrick, could you please fix xfs/for-next?
Ok, done, I think. Sorry for the mess, I hadn't ever done 'shared
development branch merging into other tree' and clearly didn't get it
right. :/
--D
> Thanks a lot,
> Andreas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: duplicate patches in the gfs2 and xfs trees
On Thu, Jul 12, 2018 at 07:16:18AM +0200, Andreas Gruenbacher wrote:
> Hi Stephen,
>
> On 12 July 2018 at 06:41, Stephen Rothwell wrote:
> > Hi Andreas,
> >
> > On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher
> > wrote:
> >>
> >> this is what I'm seeing (git log --pretty=oneline --abbrev-commit
> >> --graph ^origin/master gfs2/for-next):
> >>
> >> * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize
> >> == PAGE_SIZE
> >> * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads
> >> * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next
> >> |\
> >> | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support
> >> to iomap_readpage_actor
> >> | * ec181f6782d8 iomap: support direct I/O to inline data
> >> | * 09230435dffd iomap: refactor iomap_dio_actor
> >> | * c03cea42149d iomap: add initial support for writes without buffer heads
> >> | * 72b4daa24129 iomap: add an iomap-based readpage and readpages
> >> implementation
> >> * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap
> >> * | 2e2834ef1797 GFS2: Fix recovery issues for spectators
> >> * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next
> >> |\ \
> >> | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end}
> >> | * | 967bcc91b044 gfs2: iomap direct I/O support
> >> | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup
> >> | * | 64bc06bb32ee gfs2: iomap buffered write support
> >> | * | d505a96a3b16 gfs2: Further iomap cleanups
> >> | |/
> >> | * e184fde6f3f5 iomap: add private pointer to struct iomap
> >> | * 63899c6f8851 iomap: add a page_done callback
> >> | * 19e0c58f6552 iomap: generic inline data handling
> >> | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously
> >> | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new
> >> | * a6d639da63ae fs: factor out a __generic_write_end helper
> >> * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t
> >> * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of
> >> posix_acl_to_xattr
> >> * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have
> >> blocks reserved
> >> * d1475c07f7ce GFS2: rgrp free blocks used incorrectly
> >> * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd
> >> * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code
> >> * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly
> >> * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole
> >> * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock
> >> * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes
> >>
> >> Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on
> >> xfs/iomap-4.19-merge. That was my initial merge from
> >> xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge
> >> commit. I've then merged our iomap-write branch into for-next, with
> >> two additional commits on top. Then comes the rest of
> >> xfs/iomap-4.19-merge (that branch has moved ahead in the meantime),
> >> again with two more commits on top.
> >>
> >> There are no rebased commits, you're looking at the exact same commits.
> >
> > The problem is that commits
> >
> > a6d639da63ae fs: factor out a __generic_write_end helper
> >
> > to
> >
> > 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support
> >
> > have been rebased in the xfs tree from a base of v4.18-rc1 to
> > v4.18-rc4, so that those patches now appear twice in linux-next where I
> > have merged the gfs2 tree and the xfs tree.
>
> Ah, I see now. It's xfs/for-next that contains those rebased commits
> from xfs/iomap-4.19-merge.
>
> > This has caused a few
> > conflicts today as there are more changes to the same files affected by
> > those commits in the xfs tree. to iomap_readpage_actor
> >
> > What should have happened is that those commits should not have been
> > rebased, so either the xfs tree needs rebuilding to use the old
> > commits, or your tree needs to be rebuilt using the new commits from
> > the xfs tree. This is why we do not like the rebasing of published
> > trees (especially when a subset of the tree is shared with other
> > developers).
> >
> > Also, if you are going to merge (part of) another tree you need to make
> > sure that the other maintainer will not do a rebase of it (I assume
> > that this was probably talked about).
>
> Indeed, the idea of setting up xfs/iomap-4.19-merge was to have a
> common base that xfs/for-next and gfs2/for-next could both merge from.
> Darrick, could you please fix xfs/for-next?
Ok, done, I think. Sorry for the mess, I hadn't ever done 'shared
development branch merging into other tree' and clearly didn't get it
right. :/
--D
> Thanks a lot,
> Andreas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MAINTAINERS: Add samples/mic/
Signed-off-by: Constantine Shulyupin --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index b40d702337f2..42c439b5cd6a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7303,6 +7303,7 @@ F:drivers/misc/mic/ F: drivers/dma/mic_x100_dma.c F: drivers/dma/mic_x100_dma.h F: Documentation/mic/ +F: samples/mic/ INTEL PMC CORE DRIVER M: Rajneesh Bhardwaj -- 2.17.1
[PATCH 02/31] usb: usbssp: Added some decoding functions.
This patch add additional functions that converts some fields to string.
For example function usbssp_trb_comp_code_string take completion c
ode value and return string describing completion code.
Signed-off-by: Pawel Laszczak
---
drivers/usb/usbssp/gadget.h | 572
1 file changed, 572 insertions(+)
diff --git a/drivers/usb/usbssp/gadget.h b/drivers/usb/usbssp/gadget.h
index 486e868068b7..6b634dc63d9e 100644
--- a/drivers/usb/usbssp/gadget.h
+++ b/drivers/usb/usbssp/gadget.h
@@ -922,6 +922,73 @@ struct usbssp_transfer_event {
#define COMP_UNDEFINED_ERROR 33
#define COMP_INVALID_STREAM_ID_ERROR 34
+static inline const char *usbssp_trb_comp_code_string(u8 status)
+{
+ switch (status) {
+ case COMP_INVALID:
+ return "Invalid";
+ case COMP_SUCCESS:
+ return "Success";
+ case COMP_DATA_BUFFER_ERROR:
+ return "Data Buffer Error";
+ case COMP_BABBLE_DETECTED_ERROR:
+ return "Babble Detected";
+ case COMP_USB_TRANSACTION_ERROR:
+ return "USB Transaction Error";
+ case COMP_TRB_ERROR:
+ return "TRB Error";
+ case COMP_RESOURCE_ERROR:
+ return "Resource Error";
+ case COMP_NO_SLOTS_AVAILABLE_ERROR:
+ return "No Slots Available Error";
+ case COMP_INVALID_STREAM_TYPE_ERROR:
+ return "Invalid Stream Type Error";
+ case COMP_SLOT_NOT_ENABLED_ERROR:
+ return "Slot Not Enabled Error";
+ case COMP_ENDPOINT_NOT_ENABLED_ERROR:
+ return "Endpoint Not Enabled Error";
+ case COMP_SHORT_PACKET:
+ return "Short Packet";
+ case COMP_RING_UNDERRUN:
+ return "Ring Underrun";
+ case COMP_RING_OVERRUN:
+ return "Ring Overrun";
+ case COMP_VF_EVENT_RING_FULL_ERROR:
+ return "VF Event Ring Full Error";
+ case COMP_PARAMETER_ERROR:
+ return "Parameter Error";
+ case COMP_CONTEXT_STATE_ERROR:
+ return "Context State Error";
+ case COMP_EVENT_RING_FULL_ERROR:
+ return "Event Ring Full Error";
+ case COMP_INCOMPATIBLE_DEVICE_ERROR:
+ return "Incompatible Device Error";
+ case COMP_MISSED_SERVICE_ERROR:
+ return "Missed Service Error";
+ case COMP_COMMAND_RING_STOPPED:
+ return "Command Ring Stopped";
+ case COMP_COMMAND_ABORTED:
+ return "Command Aborted";
+ case COMP_STOPPED:
+ return "Stopped";
+ case COMP_STOPPED_LENGTH_INVALID:
+ return "Stopped - Length Invalid";
+ case COMP_STOPPED_SHORT_PACKET:
+ return "Stopped - Short Packet";
+ case COMP_MAX_EXIT_LATENCY_TOO_LARGE_ERROR:
+ return "Max Exit Latency Too Large Error";
+ case COMP_ISOCH_BUFFER_OVERRUN:
+ return "Isoch Buffer Overrun";
+ case COMP_EVENT_LOST_ERROR:
+ return "Event Lost Error";
+ case COMP_UNDEFINED_ERROR:
+ return "Undefined Error";
+ case COMP_INVALID_STREAM_ID_ERROR:
+ return "Invalid Stream ID Error";
+ default:
+ return "Unknown!!";
+ }
+}
struct usbssp_link_trb {
/* 64-bit segment pointer*/
__le64 segment_ptr;
@@ -1274,6 +1341,27 @@ enum usbssp_ring_type {
TYPE_EVENT,
};
+static inline const char *usbssp_ring_type_string(enum usbssp_ring_type type)
+{
+ switch (type) {
+ case TYPE_CTRL:
+ return "CTRL";
+ case TYPE_ISOC:
+ return "ISOC";
+ case TYPE_BULK:
+ return "BULK";
+ case TYPE_INTR:
+ return "INTR";
+ case TYPE_STREAM:
+ return "STREAM";
+ case TYPE_COMMAND:
+ return "CMD";
+ case TYPE_EVENT:
+ return "EVENT";
+ }
+
+ return "UNKNOWN";
+}
struct usbssp_ring {
struct usbssp_segment *first_seg;
struct usbssp_segment *last_seg;
@@ -1564,4 +1652,488 @@ struct usbssp_udc {
#define usbssp_info(usbssp_data, fmt, args...) \
dev_info(usbssp_data->dev, fmt, ## args)
+/*
+ * Registers should always be accessed with double word or quad word accesses.
+ *
+ * Registers with 64-bit address pointers should be written to with
+ * dword accesses by writing the low dword first (ptr[0]), then the high dword
+ * (ptr[1]) second. DC implementations that do not support 64-bit address
+ * pointers will ignore the high dword, and write order is irrelevant.
+ */
+static inline u64 usbssp_read_64(const struct usbssp_udc *usbssp_data,
+ __le64 __iomem *regs)
+{
+ return lo_hi_readq(regs);
+}
+
+static inline void usbssp_write_64(struct usbssp_udc *usbssp_data,
+const u64 val, __le64 __iomem *regs)
+{
+ lo_hi_writeq(val, regs);
+}
[PATCH 01/31] usb: usbssp: Defined register maps and other useful structures.
It is a first patch introduce Cadence USBSSP DRD
controller. This patch is related to device side.
Device part of USBSSP controller base on standard
XHCI specification.
File define macros used bye USBSSP controller,
structures holding and grouping registers, and other
object that are used by device controller.
Register map include:
struct usbssp_cap_regs - Capabilities Register Set.
struct usbssp_op_regs - Operational Register Set.
struct usbssp_intr_reg - Interrupter Register Set.
struct usbssp_run_regs - Runtime Register Set.
Object used by hardware includes:
struct usbssp_doorbell_array - array used for arming command and
transfer rings.
struct usbssp_slot_ctx - holds information related to Slot Context.
struct usbssp_ep_ctx - hold information related to Endpoint Context.
struct usbssp_input_control_ctx - hold information about
Input Control Context.
struct usbssp_link_trb - define link TRB.
struct usbssp_transfer_event - define Transfer Event TRB.
struct usbssp_event_cmd - define Command Event TRB.
struct usbssp_generic_trb - generic used TRB object.
Patch also add some high level object that hold information
used in driver.
Some of them are:
struct usbssp_udc - main object in driver which is passed
as parameter to most of function in driver and allows
to access to all other structures.
struct usbssp_ep - holds information related to USB endpoint.
struct usbssp_command - describe command send to Event Ring.
struct usbssp_device - holds information relate do USB device.
struct usbssp_segment - holds information describing segments of TRBs.
struct usbssp_td - hold information about Transfer Descriptor.
struct usbssp_ring - holds information related to Transfer, Event or
Command ring.
struct usbssp_request - holds information related to single transfer.
Signed-off-by: Pawel Laszczak
---
drivers/usb/usbssp/gadget.h | 1567 +++
1 file changed, 1567 insertions(+)
create mode 100644 drivers/usb/usbssp/gadget.h
diff --git a/drivers/usb/usbssp/gadget.h b/drivers/usb/usbssp/gadget.h
new file mode 100644
index ..486e868068b7
--- /dev/null
+++ b/drivers/usb/usbssp/gadget.h
@@ -0,0 +1,1567 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * USBSSP device controller driver
+ *
+ * Copyright (C) 2018 Cadence.
+ *
+ * Author: Pawel Laszczak
+ *
+ * A lot of code based on Linux XHCI driver.
+ * Origin: Copyright (C) 2008 Intel Corp.
+ */
+
+#ifndef __LINUX_USBSSP_GADGET_H
+#define __LINUX_USBSSP_GADGET_H
+
+#include
+#include
+#include
+#include
+#include
+
+/* Max number slots - only 1 is allowed */
+#define DEV_MAX_SLOTS 1
+
+/* max ports for USBSSP-Dev - only 2 are allowed*/
+#define MAX_USBSSP_PORTS 2
+
+#define USBSSP_EP0_SETUP_SIZE 512
+
+/*16 for in and 16 for out */
+#define USBSSP_ENDPOINTS_NUM 32
+
+/* HCSPARAMS1 - hcs_params1 - bitmasks */
+/* bits 0:7, Max Device Slots */
+#define DEV_HCS_MAX_SLOTS(p) (((p) >> 0) & 0xff)
+#define DEV_HCS_SLOTS_MASK 0xff
+
+/*
+ * USBSSP register interface.
+ */
+/**
+ * struct usbssp_cap_regs - USBSSP Registers.
+ * @hc_capbase:length of the capabilities register and DC
version number
+ * @hcs_params1: HCSPARAMS1 - Structural Parameters 1
+ * @hcs_params2: HCSPARAMS2 - Structural Parameters 2
+ * @hcs_params3: HCSPARAMS3 - Structural Parameters 3
+ * @hcc_params:HCCPARAMS - Capability Parameters
+ * @db_off:DBOFF - Doorbell array offset
+ * @run_regs_off: RTSOFF - Runtime register space offset
+ * @hcc_params2: HCCPARAMS2 Capability Parameters 2,
+ */
+struct usbssp_cap_regs {
+ __le32 hc_capbase;
+ __le32 hcs_params1;
+ __le32 hcs_params2;
+ __le32 hcs_params3;
+ __le32 hcc_params;
+ __le32 db_off;
+ __le32 run_regs_off;
+ __le32 hcc_params2;
+ /* Reserved up to (CAPLENGTH - 0x1C) */
+};
+
+/* hc_capbase bitmasks */
+/* bits 7:0 - how long is the Capabilities register */
+#define HC_LENGTH(p) USBSSP_HC_LENGTH(p)
+/* bits 31:16 */
+#define HC_VERSION(p) (((p) >> 16) & 0x)
+
+/* HCSPARAMS1 - hcs_params1 - bitmasks */
+/* bits 0:7, Max Device Slots */
+#define HCS_MAX_SLOTS(p) (((p) >> 0) & 0xff)
+#define HCS_SLOTS_MASK 0xff
+/* bits 8:18, Max Interrupters */
+#define HCS_MAX_INTRS(p) (((p) >> 8) & 0x7ff)
+/* bits 24:31, Max Ports - max value is 0x7F = 127 ports */
+#define HCS_MAX_PORTS(p) (((p) >> 24) & 0x7f)
+
+/* HCSPARAMS2 - hcs_params2 - bitmasks */
+/* bits 0:3, Isochronous Scheduling Threshold (IST)*/
+#define HCS_IST(p) (((p) >> 0) & 0xf)
+/* bits 4:7, max number of Event Ring segments */
+#define HCS_ERST_MAX(p)(((p) >> 4) & 0xf)
+/* bits 21:25 Hi 5 bits of Scratchpad buffers SW must allocate for the HW */
+/* bit 26 Scratchpad restore - for save/restore HW state - not used yet */
+/* bits 27:31 Lo 5 bits of Scratchpad buffers SW must allocate
[PATCH 03/31] usb: usbssp: Add trace events used in driver
This patch creates a set of event class. For each event class this patch defines some trace events. 1. event class: usbssp_log_msg - usbssp_dbg_address - debug message used in function handling Address Device Command. - usbssp_dbg_context_change - debug messages related to contexti updates performed with Configure Endpoint and Evaluate Contexti command. - usbssp_dbg_reset_ep - debug messages associated with resetting i an endpoint. - usbssp_dbg_cancel_request - debug messages related to the removal of a cancelled Request. - usbssp_dbg_init - debug messages related to the initialization and unload. - usbssp_dbg_ring_expansion - debug messages related to ring expansion. 2. event class: usbssp_log_ctx usbssp_address_ctx - debug message related to address Device command, that can be used to display the context data filed. 3. event class: usbssp_log_trb - usbssp_handle_event - debug message related to handling Events TRB. - usbssp_handle_command - debug message related to handling C ommand TRB. - usbssp_handle_transfer - debug message related to handling Transfer TRB. - usbssp_queue_trb - debug message related to queuing TRB. 4. event class: usbssp_log_priv_dev This class event tracing at least part of an usbssp_device lifetime, and for now it already exposes quite a bit of valuable information. - usbssp_alloc_priv_device - debug message related to allocating device. - usbssp_free_priv_device - debug message related to the freeing device. - usbssp_setup_addressable_priv_device - debug message related to the initialization of usbssp_device object. - usbssp_setup_device - debug message related to Address Device command. - usbssp_stop_device - debug message related to stooping device. 5. event class: usbssp_log_request This will help us figuring out information related to usb_request object. - usbssp_request_enqueue - debug message used during enqueuing new request. - usbssp_request_giveback - debug message related to usbssp_request_giveback function - usbssp_request_dequeue - debug message related to dequeuing request. - usbssp_alloc_request - debug message related to allocation new request. - usbssp_free_request - debug message related to freeing request. 6. event class: usbssp_log_ep_ctx With these event class, we can track what's happening with the HW while executing each and every command. It will give us visibility into how the endpoint contexts are being modified by controller which can bring insight into problems while debugging. - usbssp_remove_request - debug message related to removing request. - usbssp_handle_cmd_stop_ep - debug message related to Stop Endpointi command. - usbssp_handle_cmd_set_deq_ep - debug message releted to Set Dequeue Endpoint command, - usbssp_handle_cmd_reset_ep - debug message related to Reset Endpoint command. - usbssp_handle_cmd_config_ep - debug message related to Endpoint Configure command. 7. event class: usbssp_log_slot_ctx With these event class, we can track what's happening with the HW while executing each and every command. It will give us visibility into how the slot contexts are being modified by controller which can bring insight into problems while debugging. - usbssp_alloc_dev - debug message related to allocating device. - usbssp_free_dev - debug message related to freeing device. - usbssp_handle_cmd_disable_slot - debug message related to Disable Slot command. - usbssp_reset_device - debug message related to resetting device. - usbssp_setup_device_slot - debug message related to c onfiguring slot. - usbssp_handle_cmd_addr_dev - debug message related to Address Device command. - usbssp_handle_cmd_reset_dev - debug message related to Reset Device command. - usbssp_handle_cmd_set_deq - debug message related to Set Dequeue command. - usbssp_configure_endpoint - debug message used during configuring endpoints. 8. event class: usbssp_log_ring This event class defines the events used for tracing the change of all kinds of rings used by an usbssp device. An usbssp ring is basically a memory block shared between software and hardware. By tracing changes of rings, it makes the life easier for. - debugging hardware or software problems. - usbssp_ring_alloc - debug message related to allocation ring. - usbssp_ring_free - debug message related to freeing ring. - usbssp_ring_expansion - debug message related with expansion ring. - usbssp_inc_enq - debug message related with incrementing dequeue pointer. - usbssp_inc_deq - debug message related with decrementing dequeue pointer. 9. event class:
[PATCH] MAINTAINERS: Add samples/mic/
Signed-off-by: Constantine Shulyupin --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index b40d702337f2..42c439b5cd6a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7303,6 +7303,7 @@ F:drivers/misc/mic/ F: drivers/dma/mic_x100_dma.c F: drivers/dma/mic_x100_dma.h F: Documentation/mic/ +F: samples/mic/ INTEL PMC CORE DRIVER M: Rajneesh Bhardwaj -- 2.17.1
[PATCH 02/31] usb: usbssp: Added some decoding functions.
This patch add additional functions that converts some fields to string.
For example function usbssp_trb_comp_code_string take completion c
ode value and return string describing completion code.
Signed-off-by: Pawel Laszczak
---
drivers/usb/usbssp/gadget.h | 572
1 file changed, 572 insertions(+)
diff --git a/drivers/usb/usbssp/gadget.h b/drivers/usb/usbssp/gadget.h
index 486e868068b7..6b634dc63d9e 100644
--- a/drivers/usb/usbssp/gadget.h
+++ b/drivers/usb/usbssp/gadget.h
@@ -922,6 +922,73 @@ struct usbssp_transfer_event {
#define COMP_UNDEFINED_ERROR 33
#define COMP_INVALID_STREAM_ID_ERROR 34
+static inline const char *usbssp_trb_comp_code_string(u8 status)
+{
+ switch (status) {
+ case COMP_INVALID:
+ return "Invalid";
+ case COMP_SUCCESS:
+ return "Success";
+ case COMP_DATA_BUFFER_ERROR:
+ return "Data Buffer Error";
+ case COMP_BABBLE_DETECTED_ERROR:
+ return "Babble Detected";
+ case COMP_USB_TRANSACTION_ERROR:
+ return "USB Transaction Error";
+ case COMP_TRB_ERROR:
+ return "TRB Error";
+ case COMP_RESOURCE_ERROR:
+ return "Resource Error";
+ case COMP_NO_SLOTS_AVAILABLE_ERROR:
+ return "No Slots Available Error";
+ case COMP_INVALID_STREAM_TYPE_ERROR:
+ return "Invalid Stream Type Error";
+ case COMP_SLOT_NOT_ENABLED_ERROR:
+ return "Slot Not Enabled Error";
+ case COMP_ENDPOINT_NOT_ENABLED_ERROR:
+ return "Endpoint Not Enabled Error";
+ case COMP_SHORT_PACKET:
+ return "Short Packet";
+ case COMP_RING_UNDERRUN:
+ return "Ring Underrun";
+ case COMP_RING_OVERRUN:
+ return "Ring Overrun";
+ case COMP_VF_EVENT_RING_FULL_ERROR:
+ return "VF Event Ring Full Error";
+ case COMP_PARAMETER_ERROR:
+ return "Parameter Error";
+ case COMP_CONTEXT_STATE_ERROR:
+ return "Context State Error";
+ case COMP_EVENT_RING_FULL_ERROR:
+ return "Event Ring Full Error";
+ case COMP_INCOMPATIBLE_DEVICE_ERROR:
+ return "Incompatible Device Error";
+ case COMP_MISSED_SERVICE_ERROR:
+ return "Missed Service Error";
+ case COMP_COMMAND_RING_STOPPED:
+ return "Command Ring Stopped";
+ case COMP_COMMAND_ABORTED:
+ return "Command Aborted";
+ case COMP_STOPPED:
+ return "Stopped";
+ case COMP_STOPPED_LENGTH_INVALID:
+ return "Stopped - Length Invalid";
+ case COMP_STOPPED_SHORT_PACKET:
+ return "Stopped - Short Packet";
+ case COMP_MAX_EXIT_LATENCY_TOO_LARGE_ERROR:
+ return "Max Exit Latency Too Large Error";
+ case COMP_ISOCH_BUFFER_OVERRUN:
+ return "Isoch Buffer Overrun";
+ case COMP_EVENT_LOST_ERROR:
+ return "Event Lost Error";
+ case COMP_UNDEFINED_ERROR:
+ return "Undefined Error";
+ case COMP_INVALID_STREAM_ID_ERROR:
+ return "Invalid Stream ID Error";
+ default:
+ return "Unknown!!";
+ }
+}
struct usbssp_link_trb {
/* 64-bit segment pointer*/
__le64 segment_ptr;
@@ -1274,6 +1341,27 @@ enum usbssp_ring_type {
TYPE_EVENT,
};
+static inline const char *usbssp_ring_type_string(enum usbssp_ring_type type)
+{
+ switch (type) {
+ case TYPE_CTRL:
+ return "CTRL";
+ case TYPE_ISOC:
+ return "ISOC";
+ case TYPE_BULK:
+ return "BULK";
+ case TYPE_INTR:
+ return "INTR";
+ case TYPE_STREAM:
+ return "STREAM";
+ case TYPE_COMMAND:
+ return "CMD";
+ case TYPE_EVENT:
+ return "EVENT";
+ }
+
+ return "UNKNOWN";
+}
struct usbssp_ring {
struct usbssp_segment *first_seg;
struct usbssp_segment *last_seg;
@@ -1564,4 +1652,488 @@ struct usbssp_udc {
#define usbssp_info(usbssp_data, fmt, args...) \
dev_info(usbssp_data->dev, fmt, ## args)
+/*
+ * Registers should always be accessed with double word or quad word accesses.
+ *
+ * Registers with 64-bit address pointers should be written to with
+ * dword accesses by writing the low dword first (ptr[0]), then the high dword
+ * (ptr[1]) second. DC implementations that do not support 64-bit address
+ * pointers will ignore the high dword, and write order is irrelevant.
+ */
+static inline u64 usbssp_read_64(const struct usbssp_udc *usbssp_data,
+ __le64 __iomem *regs)
+{
+ return lo_hi_readq(regs);
+}
+
+static inline void usbssp_write_64(struct usbssp_udc *usbssp_data,
+const u64 val, __le64 __iomem *regs)
+{
+ lo_hi_writeq(val, regs);
+}
[PATCH 01/31] usb: usbssp: Defined register maps and other useful structures.
It is a first patch introduce Cadence USBSSP DRD
controller. This patch is related to device side.
Device part of USBSSP controller base on standard
XHCI specification.
File define macros used bye USBSSP controller,
structures holding and grouping registers, and other
object that are used by device controller.
Register map include:
struct usbssp_cap_regs - Capabilities Register Set.
struct usbssp_op_regs - Operational Register Set.
struct usbssp_intr_reg - Interrupter Register Set.
struct usbssp_run_regs - Runtime Register Set.
Object used by hardware includes:
struct usbssp_doorbell_array - array used for arming command and
transfer rings.
struct usbssp_slot_ctx - holds information related to Slot Context.
struct usbssp_ep_ctx - hold information related to Endpoint Context.
struct usbssp_input_control_ctx - hold information about
Input Control Context.
struct usbssp_link_trb - define link TRB.
struct usbssp_transfer_event - define Transfer Event TRB.
struct usbssp_event_cmd - define Command Event TRB.
struct usbssp_generic_trb - generic used TRB object.
Patch also add some high level object that hold information
used in driver.
Some of them are:
struct usbssp_udc - main object in driver which is passed
as parameter to most of function in driver and allows
to access to all other structures.
struct usbssp_ep - holds information related to USB endpoint.
struct usbssp_command - describe command send to Event Ring.
struct usbssp_device - holds information relate do USB device.
struct usbssp_segment - holds information describing segments of TRBs.
struct usbssp_td - hold information about Transfer Descriptor.
struct usbssp_ring - holds information related to Transfer, Event or
Command ring.
struct usbssp_request - holds information related to single transfer.
Signed-off-by: Pawel Laszczak
---
drivers/usb/usbssp/gadget.h | 1567 +++
1 file changed, 1567 insertions(+)
create mode 100644 drivers/usb/usbssp/gadget.h
diff --git a/drivers/usb/usbssp/gadget.h b/drivers/usb/usbssp/gadget.h
new file mode 100644
index ..486e868068b7
--- /dev/null
+++ b/drivers/usb/usbssp/gadget.h
@@ -0,0 +1,1567 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * USBSSP device controller driver
+ *
+ * Copyright (C) 2018 Cadence.
+ *
+ * Author: Pawel Laszczak
+ *
+ * A lot of code based on Linux XHCI driver.
+ * Origin: Copyright (C) 2008 Intel Corp.
+ */
+
+#ifndef __LINUX_USBSSP_GADGET_H
+#define __LINUX_USBSSP_GADGET_H
+
+#include
+#include
+#include
+#include
+#include
+
+/* Max number slots - only 1 is allowed */
+#define DEV_MAX_SLOTS 1
+
+/* max ports for USBSSP-Dev - only 2 are allowed*/
+#define MAX_USBSSP_PORTS 2
+
+#define USBSSP_EP0_SETUP_SIZE 512
+
+/*16 for in and 16 for out */
+#define USBSSP_ENDPOINTS_NUM 32
+
+/* HCSPARAMS1 - hcs_params1 - bitmasks */
+/* bits 0:7, Max Device Slots */
+#define DEV_HCS_MAX_SLOTS(p) (((p) >> 0) & 0xff)
+#define DEV_HCS_SLOTS_MASK 0xff
+
+/*
+ * USBSSP register interface.
+ */
+/**
+ * struct usbssp_cap_regs - USBSSP Registers.
+ * @hc_capbase:length of the capabilities register and DC
version number
+ * @hcs_params1: HCSPARAMS1 - Structural Parameters 1
+ * @hcs_params2: HCSPARAMS2 - Structural Parameters 2
+ * @hcs_params3: HCSPARAMS3 - Structural Parameters 3
+ * @hcc_params:HCCPARAMS - Capability Parameters
+ * @db_off:DBOFF - Doorbell array offset
+ * @run_regs_off: RTSOFF - Runtime register space offset
+ * @hcc_params2: HCCPARAMS2 Capability Parameters 2,
+ */
+struct usbssp_cap_regs {
+ __le32 hc_capbase;
+ __le32 hcs_params1;
+ __le32 hcs_params2;
+ __le32 hcs_params3;
+ __le32 hcc_params;
+ __le32 db_off;
+ __le32 run_regs_off;
+ __le32 hcc_params2;
+ /* Reserved up to (CAPLENGTH - 0x1C) */
+};
+
+/* hc_capbase bitmasks */
+/* bits 7:0 - how long is the Capabilities register */
+#define HC_LENGTH(p) USBSSP_HC_LENGTH(p)
+/* bits 31:16 */
+#define HC_VERSION(p) (((p) >> 16) & 0x)
+
+/* HCSPARAMS1 - hcs_params1 - bitmasks */
+/* bits 0:7, Max Device Slots */
+#define HCS_MAX_SLOTS(p) (((p) >> 0) & 0xff)
+#define HCS_SLOTS_MASK 0xff
+/* bits 8:18, Max Interrupters */
+#define HCS_MAX_INTRS(p) (((p) >> 8) & 0x7ff)
+/* bits 24:31, Max Ports - max value is 0x7F = 127 ports */
+#define HCS_MAX_PORTS(p) (((p) >> 24) & 0x7f)
+
+/* HCSPARAMS2 - hcs_params2 - bitmasks */
+/* bits 0:3, Isochronous Scheduling Threshold (IST)*/
+#define HCS_IST(p) (((p) >> 0) & 0xf)
+/* bits 4:7, max number of Event Ring segments */
+#define HCS_ERST_MAX(p)(((p) >> 4) & 0xf)
+/* bits 21:25 Hi 5 bits of Scratchpad buffers SW must allocate for the HW */
+/* bit 26 Scratchpad restore - for save/restore HW state - not used yet */
+/* bits 27:31 Lo 5 bits of Scratchpad buffers SW must allocate
[PATCH 03/31] usb: usbssp: Add trace events used in driver
This patch creates a set of event class. For each event class this patch defines some trace events. 1. event class: usbssp_log_msg - usbssp_dbg_address - debug message used in function handling Address Device Command. - usbssp_dbg_context_change - debug messages related to contexti updates performed with Configure Endpoint and Evaluate Contexti command. - usbssp_dbg_reset_ep - debug messages associated with resetting i an endpoint. - usbssp_dbg_cancel_request - debug messages related to the removal of a cancelled Request. - usbssp_dbg_init - debug messages related to the initialization and unload. - usbssp_dbg_ring_expansion - debug messages related to ring expansion. 2. event class: usbssp_log_ctx usbssp_address_ctx - debug message related to address Device command, that can be used to display the context data filed. 3. event class: usbssp_log_trb - usbssp_handle_event - debug message related to handling Events TRB. - usbssp_handle_command - debug message related to handling C ommand TRB. - usbssp_handle_transfer - debug message related to handling Transfer TRB. - usbssp_queue_trb - debug message related to queuing TRB. 4. event class: usbssp_log_priv_dev This class event tracing at least part of an usbssp_device lifetime, and for now it already exposes quite a bit of valuable information. - usbssp_alloc_priv_device - debug message related to allocating device. - usbssp_free_priv_device - debug message related to the freeing device. - usbssp_setup_addressable_priv_device - debug message related to the initialization of usbssp_device object. - usbssp_setup_device - debug message related to Address Device command. - usbssp_stop_device - debug message related to stooping device. 5. event class: usbssp_log_request This will help us figuring out information related to usb_request object. - usbssp_request_enqueue - debug message used during enqueuing new request. - usbssp_request_giveback - debug message related to usbssp_request_giveback function - usbssp_request_dequeue - debug message related to dequeuing request. - usbssp_alloc_request - debug message related to allocation new request. - usbssp_free_request - debug message related to freeing request. 6. event class: usbssp_log_ep_ctx With these event class, we can track what's happening with the HW while executing each and every command. It will give us visibility into how the endpoint contexts are being modified by controller which can bring insight into problems while debugging. - usbssp_remove_request - debug message related to removing request. - usbssp_handle_cmd_stop_ep - debug message related to Stop Endpointi command. - usbssp_handle_cmd_set_deq_ep - debug message releted to Set Dequeue Endpoint command, - usbssp_handle_cmd_reset_ep - debug message related to Reset Endpoint command. - usbssp_handle_cmd_config_ep - debug message related to Endpoint Configure command. 7. event class: usbssp_log_slot_ctx With these event class, we can track what's happening with the HW while executing each and every command. It will give us visibility into how the slot contexts are being modified by controller which can bring insight into problems while debugging. - usbssp_alloc_dev - debug message related to allocating device. - usbssp_free_dev - debug message related to freeing device. - usbssp_handle_cmd_disable_slot - debug message related to Disable Slot command. - usbssp_reset_device - debug message related to resetting device. - usbssp_setup_device_slot - debug message related to c onfiguring slot. - usbssp_handle_cmd_addr_dev - debug message related to Address Device command. - usbssp_handle_cmd_reset_dev - debug message related to Reset Device command. - usbssp_handle_cmd_set_deq - debug message related to Set Dequeue command. - usbssp_configure_endpoint - debug message used during configuring endpoints. 8. event class: usbssp_log_ring This event class defines the events used for tracing the change of all kinds of rings used by an usbssp device. An usbssp ring is basically a memory block shared between software and hardware. By tracing changes of rings, it makes the life easier for. - debugging hardware or software problems. - usbssp_ring_alloc - debug message related to allocation ring. - usbssp_ring_free - debug message related to freeing ring. - usbssp_ring_expansion - debug message related with expansion ring. - usbssp_inc_enq - debug message related with incrementing dequeue pointer. - usbssp_inc_deq - debug message related with decrementing dequeue pointer. 9. event class:
Re: Bug report about KASLR and ZONE_MOVABLE
Hi Baoquan,
At 07/11/2018 08:40 PM, Baoquan He wrote:
Please try this v3 patch:
>>From 9850d3de9c02e570dc7572069a9749a8add4c4c7 Mon Sep 17 00:00:00 2001
From: Baoquan He
Date: Wed, 11 Jul 2018 20:31:51 +0800
Subject: [PATCH v3] mm, page_alloc: find movable zone after kernel text
In find_zone_movable_pfns_for_nodes(), when try to find the starting
PFN movable zone begins in each node, kernel text position is not
considered. KASLR may put kernel after which movable zone begins.
Fix it by finding movable zone after kernel text on that node.
Signed-off-by: Baoquan He
You fix this in the _zone_init side_. This may make the 'kernelcore=' or
'movablecore=' failed if the KASLR puts the kernel back the tail of the
last node, or more.
Due to we have fix the mirror memory in KASLR side, and Chao is trying
to fix the 'movable_node' in KASLR side. Have you had a chance to fix
this in the KASLR side.
---
mm/page_alloc.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 1521100..390eb35 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6547,7 +6547,7 @@ static unsigned long __init
early_calculate_totalpages(void)
static void __init find_zone_movable_pfns_for_nodes(void)
{
int i, nid;
- unsigned long usable_startpfn;
+ unsigned long usable_startpfn, real_startpfn;
unsigned long kernelcore_node, kernelcore_remaining;
/* save the state before borrow the nodemask */
nodemask_t saved_node_state = node_states[N_MEMORY];
@@ -6681,10 +6681,20 @@ static void __init
find_zone_movable_pfns_for_nodes(void)
if (start_pfn >= end_pfn)
continue;
+ /*
+* KASLR may put kernel near tail of node memory,
+* start after kernel on that node to find PFN
+* which zone begins.
+*/
+ if (pfn_to_nid(PFN_UP(_etext)) == i)
Here, did you want to check the Node id? seems may be nid.
and
for_each_node_state(nid, N_MEMORY) {
... seems check here is more suitable.
for_each_mem_pfn_range(i, nid, _pfn, _pfn, NULL) {
}
}
Thanks,
dou
+ real_startpfn = max(usable_startpfn,
+ PFN_UP(_etext))
+ else
+ real_startpfn = usable_startpfn;
/* Account for what is only usable for kernelcore */
- if (start_pfn < usable_startpfn) {
+ if (start_pfn < real_startpfn) {
unsigned long kernel_pages;
- kernel_pages = min(end_pfn, usable_startpfn)
+ kernel_pages = min(end_pfn, real_startpfn)
- start_pfn;
kernelcore_remaining -= min(kernel_pages,
@@ -6693,7 +6703,7 @@ static void __init find_zone_movable_pfns_for_nodes(void)
required_kernelcore);
/* Continue if range is now fully accounted */
- if (end_pfn <= usable_startpfn) {
+ if (end_pfn <= real_startpfn) {
/*
* Push zone_movable_pfn to the end so
@@ -6704,7 +6714,7 @@ static void __init find_zone_movable_pfns_for_nodes(void)
zone_movable_pfn[nid] = end_pfn;
continue;
}
- start_pfn = usable_startpfn;
+ start_pfn = real_startpfn;
}
/*
[PATCH 09/31] usb: usbssp: add implementation of usbssp_mem_cleanup
Patch add implementation of usbssp_mem_cleanup and
all other functions used during cleaning driver during
unloading module.
Signed-off-by: Pawel Laszczak
---
drivers/usb/usbssp/gadget-mem.c | 180 ++-
drivers/usb/usbssp/gadget-ring.c | 21
drivers/usb/usbssp/gadget.c | 3 +-
drivers/usb/usbssp/gadget.h | 10 ++
4 files changed, 211 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/usbssp/gadget-mem.c b/drivers/usb/usbssp/gadget-mem.c
index b3d86d400dba..6ee068592ba4 100644
--- a/drivers/usb/usbssp/gadget-mem.c
+++ b/drivers/usb/usbssp/gadget-mem.c
@@ -498,6 +498,103 @@ struct usbssp_container_ctx *usbssp_alloc_container_ctx(
return ctx;
}
+void usbssp_free_container_ctx(struct usbssp_udc *usbssp_data,
+ struct usbssp_container_ctx *ctx)
+{
+ if (!ctx)
+ return;
+ dma_pool_free(usbssp_data->device_pool, ctx->bytes, ctx->dma);
+ kfree(ctx);
+}
+
+/* Streams structures manipulation */
+static void usbssp_free_stream_ctx(struct usbssp_udc *usbssp_data,
+ unsigned int num_stream_ctxs,
+ struct usbssp_stream_ctx *stream_ctx,
+ dma_addr_t dma)
+{
+ struct device *dev = usbssp_data->dev;
+ size_t size = sizeof(struct usbssp_stream_ctx) * num_stream_ctxs;
+
+ if (size > MEDIUM_STREAM_ARRAY_SIZE)
+ dma_free_coherent(dev, size, stream_ctx, dma);
+ else if (size <= SMALL_STREAM_ARRAY_SIZE)
+ return dma_pool_free(usbssp_data->small_streams_pool,
+ stream_ctx, dma);
+ else
+ return dma_pool_free(usbssp_data->medium_streams_pool,
+ stream_ctx, dma);
+}
+/* Frees all stream contexts associated with the endpoint,
+ *
+ * Caller should fix the endpoint context streams fields.
+ */
+void usbssp_free_stream_info(struct usbssp_udc *usbssp_data,
+struct usbssp_stream_info *stream_info)
+{
+ int cur_stream;
+ struct usbssp_ring *cur_ring;
+
+ if (!stream_info)
+ return;
+
+ for (cur_stream = 1; cur_stream < stream_info->num_streams;
+ cur_stream++) {
+ cur_ring = stream_info->stream_rings[cur_stream];
+ if (cur_ring) {
+ usbssp_ring_free(usbssp_data, cur_ring);
+ stream_info->stream_rings[cur_stream] = NULL;
+ }
+ }
+ usbssp_free_command(usbssp_data, stream_info->free_streams_command);
+ usbssp_data->cmd_ring_reserved_trbs--;
+ if (stream_info->stream_ctx_array)
+ usbssp_free_stream_ctx(usbssp_data,
+ stream_info->num_stream_ctxs,
+ stream_info->stream_ctx_array,
+ stream_info->ctx_array_dma);
+
+ kfree(stream_info->stream_rings);
+ kfree(stream_info);
+}
+
+/* Device context manipulation */
+
+/* All the usbssp_tds in the ring's TD list should be freed at this point.
+ */
+void usbssp_free_priv_device(struct usbssp_udc *usbssp_data)
+{
+ struct usbssp_device *dev;
+ int i;
+
+ /* if slot_id = 0 then no device slot is used */
+ if (usbssp_data->slot_id == 0)
+ return;
+
+ dev = _data->devs;
+ trace_usbssp_free_priv_device(dev);
+
+ usbssp_data->dcbaa->dev_context_ptrs[usbssp_data->slot_id] = 0;
+ if (!dev)
+ return;
+
+ for (i = 0; i < 31; ++i) {
+ if (dev->eps[i].ring)
+ usbssp_ring_free(usbssp_data, dev->eps[i].ring);
+
+ if (dev->eps[i].stream_info) {
+ usbssp_free_stream_info(usbssp_data,
+ dev->eps[i].stream_info);
+ }
+ }
+
+ if (dev->in_ctx)
+ usbssp_free_container_ctx(usbssp_data, dev->in_ctx);
+ if (dev->out_ctx)
+ usbssp_free_container_ctx(usbssp_data, dev->out_ctx);
+
+ usbssp_data->slot_id = 0;
+}
struct usbssp_command *usbssp_alloc_command(struct usbssp_udc *usbssp_data,
bool allocate_completion,
gfp_t mem_flags)
@@ -552,6 +649,13 @@ void usbssp_request_free_priv(struct usbssp_request
*priv_req)
kfree(priv_req->td);
}
+void usbssp_free_command(struct usbssp_udc *usbssp_data,
+struct usbssp_command *command)
+{
+ usbssp_free_container_ctx(usbssp_data, command->in_ctx);
+ kfree(command->completion);
+ kfree(command);
+}
int usbssp_alloc_erst(struct usbssp_udc *usbssp_data,
struct usbssp_ring *evt_ring,
@@ -583,9 +687,83 @@ int usbssp_alloc_erst(struct
Re: Bug report about KASLR and ZONE_MOVABLE
Hi Baoquan,
At 07/11/2018 08:40 PM, Baoquan He wrote:
Please try this v3 patch:
>>From 9850d3de9c02e570dc7572069a9749a8add4c4c7 Mon Sep 17 00:00:00 2001
From: Baoquan He
Date: Wed, 11 Jul 2018 20:31:51 +0800
Subject: [PATCH v3] mm, page_alloc: find movable zone after kernel text
In find_zone_movable_pfns_for_nodes(), when try to find the starting
PFN movable zone begins in each node, kernel text position is not
considered. KASLR may put kernel after which movable zone begins.
Fix it by finding movable zone after kernel text on that node.
Signed-off-by: Baoquan He
You fix this in the _zone_init side_. This may make the 'kernelcore=' or
'movablecore=' failed if the KASLR puts the kernel back the tail of the
last node, or more.
Due to we have fix the mirror memory in KASLR side, and Chao is trying
to fix the 'movable_node' in KASLR side. Have you had a chance to fix
this in the KASLR side.
---
mm/page_alloc.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 1521100..390eb35 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6547,7 +6547,7 @@ static unsigned long __init
early_calculate_totalpages(void)
static void __init find_zone_movable_pfns_for_nodes(void)
{
int i, nid;
- unsigned long usable_startpfn;
+ unsigned long usable_startpfn, real_startpfn;
unsigned long kernelcore_node, kernelcore_remaining;
/* save the state before borrow the nodemask */
nodemask_t saved_node_state = node_states[N_MEMORY];
@@ -6681,10 +6681,20 @@ static void __init
find_zone_movable_pfns_for_nodes(void)
if (start_pfn >= end_pfn)
continue;
+ /*
+* KASLR may put kernel near tail of node memory,
+* start after kernel on that node to find PFN
+* which zone begins.
+*/
+ if (pfn_to_nid(PFN_UP(_etext)) == i)
Here, did you want to check the Node id? seems may be nid.
and
for_each_node_state(nid, N_MEMORY) {
... seems check here is more suitable.
for_each_mem_pfn_range(i, nid, _pfn, _pfn, NULL) {
}
}
Thanks,
dou
+ real_startpfn = max(usable_startpfn,
+ PFN_UP(_etext))
+ else
+ real_startpfn = usable_startpfn;
/* Account for what is only usable for kernelcore */
- if (start_pfn < usable_startpfn) {
+ if (start_pfn < real_startpfn) {
unsigned long kernel_pages;
- kernel_pages = min(end_pfn, usable_startpfn)
+ kernel_pages = min(end_pfn, real_startpfn)
- start_pfn;
kernelcore_remaining -= min(kernel_pages,
@@ -6693,7 +6703,7 @@ static void __init find_zone_movable_pfns_for_nodes(void)
required_kernelcore);
/* Continue if range is now fully accounted */
- if (end_pfn <= usable_startpfn) {
+ if (end_pfn <= real_startpfn) {
/*
* Push zone_movable_pfn to the end so
@@ -6704,7 +6714,7 @@ static void __init find_zone_movable_pfns_for_nodes(void)
zone_movable_pfn[nid] = end_pfn;
continue;
}
- start_pfn = usable_startpfn;
+ start_pfn = real_startpfn;
}
/*
[PATCH 09/31] usb: usbssp: add implementation of usbssp_mem_cleanup
Patch add implementation of usbssp_mem_cleanup and
all other functions used during cleaning driver during
unloading module.
Signed-off-by: Pawel Laszczak
---
drivers/usb/usbssp/gadget-mem.c | 180 ++-
drivers/usb/usbssp/gadget-ring.c | 21
drivers/usb/usbssp/gadget.c | 3 +-
drivers/usb/usbssp/gadget.h | 10 ++
4 files changed, 211 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/usbssp/gadget-mem.c b/drivers/usb/usbssp/gadget-mem.c
index b3d86d400dba..6ee068592ba4 100644
--- a/drivers/usb/usbssp/gadget-mem.c
+++ b/drivers/usb/usbssp/gadget-mem.c
@@ -498,6 +498,103 @@ struct usbssp_container_ctx *usbssp_alloc_container_ctx(
return ctx;
}
+void usbssp_free_container_ctx(struct usbssp_udc *usbssp_data,
+ struct usbssp_container_ctx *ctx)
+{
+ if (!ctx)
+ return;
+ dma_pool_free(usbssp_data->device_pool, ctx->bytes, ctx->dma);
+ kfree(ctx);
+}
+
+/* Streams structures manipulation */
+static void usbssp_free_stream_ctx(struct usbssp_udc *usbssp_data,
+ unsigned int num_stream_ctxs,
+ struct usbssp_stream_ctx *stream_ctx,
+ dma_addr_t dma)
+{
+ struct device *dev = usbssp_data->dev;
+ size_t size = sizeof(struct usbssp_stream_ctx) * num_stream_ctxs;
+
+ if (size > MEDIUM_STREAM_ARRAY_SIZE)
+ dma_free_coherent(dev, size, stream_ctx, dma);
+ else if (size <= SMALL_STREAM_ARRAY_SIZE)
+ return dma_pool_free(usbssp_data->small_streams_pool,
+ stream_ctx, dma);
+ else
+ return dma_pool_free(usbssp_data->medium_streams_pool,
+ stream_ctx, dma);
+}
+/* Frees all stream contexts associated with the endpoint,
+ *
+ * Caller should fix the endpoint context streams fields.
+ */
+void usbssp_free_stream_info(struct usbssp_udc *usbssp_data,
+struct usbssp_stream_info *stream_info)
+{
+ int cur_stream;
+ struct usbssp_ring *cur_ring;
+
+ if (!stream_info)
+ return;
+
+ for (cur_stream = 1; cur_stream < stream_info->num_streams;
+ cur_stream++) {
+ cur_ring = stream_info->stream_rings[cur_stream];
+ if (cur_ring) {
+ usbssp_ring_free(usbssp_data, cur_ring);
+ stream_info->stream_rings[cur_stream] = NULL;
+ }
+ }
+ usbssp_free_command(usbssp_data, stream_info->free_streams_command);
+ usbssp_data->cmd_ring_reserved_trbs--;
+ if (stream_info->stream_ctx_array)
+ usbssp_free_stream_ctx(usbssp_data,
+ stream_info->num_stream_ctxs,
+ stream_info->stream_ctx_array,
+ stream_info->ctx_array_dma);
+
+ kfree(stream_info->stream_rings);
+ kfree(stream_info);
+}
+
+/* Device context manipulation */
+
+/* All the usbssp_tds in the ring's TD list should be freed at this point.
+ */
+void usbssp_free_priv_device(struct usbssp_udc *usbssp_data)
+{
+ struct usbssp_device *dev;
+ int i;
+
+ /* if slot_id = 0 then no device slot is used */
+ if (usbssp_data->slot_id == 0)
+ return;
+
+ dev = _data->devs;
+ trace_usbssp_free_priv_device(dev);
+
+ usbssp_data->dcbaa->dev_context_ptrs[usbssp_data->slot_id] = 0;
+ if (!dev)
+ return;
+
+ for (i = 0; i < 31; ++i) {
+ if (dev->eps[i].ring)
+ usbssp_ring_free(usbssp_data, dev->eps[i].ring);
+
+ if (dev->eps[i].stream_info) {
+ usbssp_free_stream_info(usbssp_data,
+ dev->eps[i].stream_info);
+ }
+ }
+
+ if (dev->in_ctx)
+ usbssp_free_container_ctx(usbssp_data, dev->in_ctx);
+ if (dev->out_ctx)
+ usbssp_free_container_ctx(usbssp_data, dev->out_ctx);
+
+ usbssp_data->slot_id = 0;
+}
struct usbssp_command *usbssp_alloc_command(struct usbssp_udc *usbssp_data,
bool allocate_completion,
gfp_t mem_flags)
@@ -552,6 +649,13 @@ void usbssp_request_free_priv(struct usbssp_request
*priv_req)
kfree(priv_req->td);
}
+void usbssp_free_command(struct usbssp_udc *usbssp_data,
+struct usbssp_command *command)
+{
+ usbssp_free_container_ctx(usbssp_data, command->in_ctx);
+ kfree(command->completion);
+ kfree(command);
+}
int usbssp_alloc_erst(struct usbssp_udc *usbssp_data,
struct usbssp_ring *evt_ring,
@@ -583,9 +687,83 @@ int usbssp_alloc_erst(struct
[PATCH] pinctrl: mt7622: fix probe fail by misuse the selector
From: Sean Wang
After the commit acf137951367 ("pinctrl: core: Return selector to the
pinctrl driver") and the commit 47f1242d19c3 ("pinctrl: pinmux: Return
selector to the pinctrl driver"), it's necessary to add the fixes
needed for the pin controller drivers to use the appropriate returned
selector for a negative error number returned in case of the fail at
these functions. Otherwise, the driver would have a failed probe and
that causes boot message cannot correctly output and devices fail
to acquire their own pins.
Cc: Kevin Hilman
Fixes: acf137951367 ("pinctrl: core: Return selector to the pinctrl driver")
Fixes: 47f1242d19c3 ("pinctrl: pinmux: Return selector to the pinctrl driver")
Signed-off-by: Sean Wang
---
drivers/pinctrl/mediatek/pinctrl-mt7622.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7622.c
b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
index 2411c384..6f931b8 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt7622.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
@@ -1538,7 +1538,7 @@ static int mtk_build_groups(struct mtk_pinctrl *hw)
err = pinctrl_generic_add_group(hw->pctrl, group->name,
group->pins, group->num_pins,
group->data);
- if (err) {
+ if (err < 0) {
dev_err(hw->dev, "Failed to register group %s\n",
group->name);
return err;
@@ -1559,7 +1559,7 @@ static int mtk_build_functions(struct mtk_pinctrl *hw)
func->group_names,
func->num_group_names,
func->data);
- if (err) {
+ if (err < 0) {
dev_err(hw->dev, "Failed to register function %s\n",
func->name);
return err;
--
2.7.4
[PATCH] pinctrl: mt7622: fix probe fail by misuse the selector
From: Sean Wang
After the commit acf137951367 ("pinctrl: core: Return selector to the
pinctrl driver") and the commit 47f1242d19c3 ("pinctrl: pinmux: Return
selector to the pinctrl driver"), it's necessary to add the fixes
needed for the pin controller drivers to use the appropriate returned
selector for a negative error number returned in case of the fail at
these functions. Otherwise, the driver would have a failed probe and
that causes boot message cannot correctly output and devices fail
to acquire their own pins.
Cc: Kevin Hilman
Fixes: acf137951367 ("pinctrl: core: Return selector to the pinctrl driver")
Fixes: 47f1242d19c3 ("pinctrl: pinmux: Return selector to the pinctrl driver")
Signed-off-by: Sean Wang
---
drivers/pinctrl/mediatek/pinctrl-mt7622.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7622.c
b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
index 2411c384..6f931b8 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt7622.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7622.c
@@ -1538,7 +1538,7 @@ static int mtk_build_groups(struct mtk_pinctrl *hw)
err = pinctrl_generic_add_group(hw->pctrl, group->name,
group->pins, group->num_pins,
group->data);
- if (err) {
+ if (err < 0) {
dev_err(hw->dev, "Failed to register group %s\n",
group->name);
return err;
@@ -1559,7 +1559,7 @@ static int mtk_build_functions(struct mtk_pinctrl *hw)
func->group_names,
func->num_group_names,
func->data);
- if (err) {
+ if (err < 0) {
dev_err(hw->dev, "Failed to register function %s\n",
func->name);
return err;
--
2.7.4
[PATCH] samples: fix compilation of mpssd
Errors:
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:194:0,
from /usr/include/stdlib.h:394,
from mpssd.c:23:
mpssd.c:93:10: error: initializer element is not constant
.num = htole16(MIC_VRING_ENTRIES),
mpssd.c:610:10: warning: implicit declaration of function ‘readv’;
Signed-off-by: Constantine Shulyupin
---
samples/mic/mpssd/mpssd.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/samples/mic/mpssd/mpssd.c b/samples/mic/mpssd/mpssd.c
index f42ce551bb48..9cddb9cfdc79 100644
--- a/samples/mic/mpssd/mpssd.c
+++ b/samples/mic/mpssd/mpssd.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -77,6 +78,10 @@ static struct mic_info mic_list;
#define VIRTIO_NET_HDR_F_DATA_VALID2 /* Csum is valid */
#endif
+#define __uint16_identity(x) (x)
+#define __uint64_identity(x) (x)
+#define __uint32_identity(x) (x)
+
static struct {
struct mic_device_desc dd;
struct mic_vqconfig vqconfig[2];
--
2.17.1
[PATCH 28/31] usb: usbssp: implemented usbssp_gadget_ep_disable function.
Patch implements function responsible for disabling
USB endpoint. This function is called
from USB core gadget during handling SET_CONFIGURATION or
SET_INTERFACE request, or after such events as USB_RESET or detaching
device from host.
Signed-off-by: Pawel Laszczak
---
drivers/usb/usbssp/gadget-if.c | 44 +--
drivers/usb/usbssp/gadget-mem.c | 18
drivers/usb/usbssp/gadget.c | 75 +
drivers/usb/usbssp/gadget.h | 2 +
4 files changed, 135 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/usbssp/gadget-if.c b/drivers/usb/usbssp/gadget-if.c
index 2fecc934cbce..75444eaaf699 100644
--- a/drivers/usb/usbssp/gadget-if.c
+++ b/drivers/usb/usbssp/gadget-if.c
@@ -86,13 +86,49 @@ static int usbssp_gadget_ep_enable(struct usb_ep *ep,
int usbssp_gadget_ep_disable(struct usb_ep *ep)
{
- struct usbssp_ep *ep_priv = to_usbssp_ep(ep);
- int ret = 0;
+ struct usbssp_ep *ep_priv;
+ struct usbssp_udc *usbssp_data;
+ int ep_index = 0;
+ int ret;
+ int irq_disabled_locally = 0;
+ unsigned long flags = 0;
+ struct usbssp_request *req_priv;
- if (!ep_priv)
+ ep_priv = to_usbssp_ep(ep);
+ usbssp_data = ep_priv->usbssp_data;
+ ep_index = usbssp_get_endpoint_index(ep_priv->endpoint.desc);
+
+ if (!(ep_priv->ep_state & USBSSP_EP_ENABLED)) {
+ usbssp_dbg(usbssp_data, "%s is already disabled\n",
+ ep_priv->name);
return -EINVAL;
+ }
+
+ usbssp_g_lock(irq_disabled_locally, flags);
- /*TODO: implements this function*/
+ ep_priv->ep_state |= USBSSP_EP_DISABLE_PENDING;
+
+ /*dequeue all USB request from endpoint*/
+ list_for_each_entry(req_priv, _priv->pending_list, list) {
+ usbssp_dequeue(ep_priv, req_priv);
+ }
+
+ ret = usbssp_drop_endpoint(usbssp_data, _data->gadget, ep_priv);
+ if (ret)
+ goto finish;
+
+ ret = usbssp_check_bandwidth(usbssp_data, _data->gadget);
+ if (ret)
+ goto finish;
+
+ ep_priv->ep_state &= ~USBSSP_EP_ENABLED;
+
+finish:
+ ep_priv->ep_state &= ~USBSSP_EP_DISABLE_PENDING;
+ usbssp_dbg(usbssp_data, "%s disable endpoint %s\n", ep_priv->name,
+ (ret == 0) ? "success" : "failed");
+
+ usbssp_g_unlock(irq_disabled_locally, flags);
return ret;
}
diff --git a/drivers/usb/usbssp/gadget-mem.c b/drivers/usb/usbssp/gadget-mem.c
index 303dc8fab8ad..772a43f24ca9 100644
--- a/drivers/usb/usbssp/gadget-mem.c
+++ b/drivers/usb/usbssp/gadget-mem.c
@@ -1103,6 +1103,24 @@ int usbssp_endpoint_init(struct usbssp_udc *usbssp_data,
return 0;
}
+void usbssp_endpoint_zero(struct usbssp_udc *usbssp_data,
+ struct usbssp_device *dev_priv,
+ struct usbssp_ep *ep)
+{
+ unsigned int ep_index;
+ struct usbssp_ep_ctx *ep_ctx;
+
+ ep_index = usbssp_get_endpoint_index(ep->endpoint.desc);
+ ep_ctx = usbssp_get_ep_ctx(usbssp_data, dev_priv->in_ctx, ep_index);
+
+ ep_ctx->ep_info = 0;
+ ep_ctx->ep_info2 = 0;
+ ep_ctx->deq = 0;
+ ep_ctx->tx_info = 0;
+ /* Don't free the endpoint ring until the set interface or configuration
+* request succeeds.
+*/
+}
struct usbssp_command *usbssp_alloc_command(struct usbssp_udc *usbssp_data,
bool allocate_completion,
gfp_t mem_flags)
diff --git a/drivers/usb/usbssp/gadget.c b/drivers/usb/usbssp/gadget.c
index 833647600485..bf6a147e2a16 100644
--- a/drivers/usb/usbssp/gadget.c
+++ b/drivers/usb/usbssp/gadget.c
@@ -723,6 +723,81 @@ int usbssp_dequeue(struct usbssp_ep *ep_priv, struct
usbssp_request *req_priv)
return ret;
}
+/* Drop an endpoint from a new bandwidth configuration for this device.
+ * Only one call to this function is allowed per endpoint before
+ * check_bandwidth() or reset_bandwidth() must be called.
+ * A call to usbssp_drop_endpoint() followed by a call to usbssp_add_endpoint()
+ * will add the endpoint to the schedule with possibly new parameters
+ * denoted by a different endpoint descriptor in usbssp_ep.
+ * A call to usbssp_add_endpoint() followed by a call to
+ * usbsssp_drop_endpoint() is not allowed.
+ */
+int usbssp_drop_endpoint(struct usbssp_udc *usbssp_data, struct usb_gadget *g,
+ struct usbssp_ep *dep)
+{
+ struct usbssp_container_ctx *in_ctx, *out_ctx;
+ struct usbssp_input_control_ctx *ctrl_ctx;
+ unsigned int ep_index;
+ struct usbssp_ep_ctx *ep_ctx;
+ u32 drop_flag;
+ u32 new_add_flags, new_drop_flags;
+ int ret;
+
+ ret = usbssp_check_args(usbssp_data, dep, 1, true, __func__);
+ if (ret <= 0)
+ return ret;
+
+ if (usbssp_data->usbssp_state & USBSSP_STATE_DYING)
+ return
[PATCH] samples: fix compilation of mpssd
Errors:
In file included from /usr/include/x86_64-linux-gnu/sys/types.h:194:0,
from /usr/include/stdlib.h:394,
from mpssd.c:23:
mpssd.c:93:10: error: initializer element is not constant
.num = htole16(MIC_VRING_ENTRIES),
mpssd.c:610:10: warning: implicit declaration of function ‘readv’;
Signed-off-by: Constantine Shulyupin
---
samples/mic/mpssd/mpssd.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/samples/mic/mpssd/mpssd.c b/samples/mic/mpssd/mpssd.c
index f42ce551bb48..9cddb9cfdc79 100644
--- a/samples/mic/mpssd/mpssd.c
+++ b/samples/mic/mpssd/mpssd.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -77,6 +78,10 @@ static struct mic_info mic_list;
#define VIRTIO_NET_HDR_F_DATA_VALID2 /* Csum is valid */
#endif
+#define __uint16_identity(x) (x)
+#define __uint64_identity(x) (x)
+#define __uint32_identity(x) (x)
+
static struct {
struct mic_device_desc dd;
struct mic_vqconfig vqconfig[2];
--
2.17.1
[PATCH 28/31] usb: usbssp: implemented usbssp_gadget_ep_disable function.
Patch implements function responsible for disabling
USB endpoint. This function is called
from USB core gadget during handling SET_CONFIGURATION or
SET_INTERFACE request, or after such events as USB_RESET or detaching
device from host.
Signed-off-by: Pawel Laszczak
---
drivers/usb/usbssp/gadget-if.c | 44 +--
drivers/usb/usbssp/gadget-mem.c | 18
drivers/usb/usbssp/gadget.c | 75 +
drivers/usb/usbssp/gadget.h | 2 +
4 files changed, 135 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/usbssp/gadget-if.c b/drivers/usb/usbssp/gadget-if.c
index 2fecc934cbce..75444eaaf699 100644
--- a/drivers/usb/usbssp/gadget-if.c
+++ b/drivers/usb/usbssp/gadget-if.c
@@ -86,13 +86,49 @@ static int usbssp_gadget_ep_enable(struct usb_ep *ep,
int usbssp_gadget_ep_disable(struct usb_ep *ep)
{
- struct usbssp_ep *ep_priv = to_usbssp_ep(ep);
- int ret = 0;
+ struct usbssp_ep *ep_priv;
+ struct usbssp_udc *usbssp_data;
+ int ep_index = 0;
+ int ret;
+ int irq_disabled_locally = 0;
+ unsigned long flags = 0;
+ struct usbssp_request *req_priv;
- if (!ep_priv)
+ ep_priv = to_usbssp_ep(ep);
+ usbssp_data = ep_priv->usbssp_data;
+ ep_index = usbssp_get_endpoint_index(ep_priv->endpoint.desc);
+
+ if (!(ep_priv->ep_state & USBSSP_EP_ENABLED)) {
+ usbssp_dbg(usbssp_data, "%s is already disabled\n",
+ ep_priv->name);
return -EINVAL;
+ }
+
+ usbssp_g_lock(irq_disabled_locally, flags);
- /*TODO: implements this function*/
+ ep_priv->ep_state |= USBSSP_EP_DISABLE_PENDING;
+
+ /*dequeue all USB request from endpoint*/
+ list_for_each_entry(req_priv, _priv->pending_list, list) {
+ usbssp_dequeue(ep_priv, req_priv);
+ }
+
+ ret = usbssp_drop_endpoint(usbssp_data, _data->gadget, ep_priv);
+ if (ret)
+ goto finish;
+
+ ret = usbssp_check_bandwidth(usbssp_data, _data->gadget);
+ if (ret)
+ goto finish;
+
+ ep_priv->ep_state &= ~USBSSP_EP_ENABLED;
+
+finish:
+ ep_priv->ep_state &= ~USBSSP_EP_DISABLE_PENDING;
+ usbssp_dbg(usbssp_data, "%s disable endpoint %s\n", ep_priv->name,
+ (ret == 0) ? "success" : "failed");
+
+ usbssp_g_unlock(irq_disabled_locally, flags);
return ret;
}
diff --git a/drivers/usb/usbssp/gadget-mem.c b/drivers/usb/usbssp/gadget-mem.c
index 303dc8fab8ad..772a43f24ca9 100644
--- a/drivers/usb/usbssp/gadget-mem.c
+++ b/drivers/usb/usbssp/gadget-mem.c
@@ -1103,6 +1103,24 @@ int usbssp_endpoint_init(struct usbssp_udc *usbssp_data,
return 0;
}
+void usbssp_endpoint_zero(struct usbssp_udc *usbssp_data,
+ struct usbssp_device *dev_priv,
+ struct usbssp_ep *ep)
+{
+ unsigned int ep_index;
+ struct usbssp_ep_ctx *ep_ctx;
+
+ ep_index = usbssp_get_endpoint_index(ep->endpoint.desc);
+ ep_ctx = usbssp_get_ep_ctx(usbssp_data, dev_priv->in_ctx, ep_index);
+
+ ep_ctx->ep_info = 0;
+ ep_ctx->ep_info2 = 0;
+ ep_ctx->deq = 0;
+ ep_ctx->tx_info = 0;
+ /* Don't free the endpoint ring until the set interface or configuration
+* request succeeds.
+*/
+}
struct usbssp_command *usbssp_alloc_command(struct usbssp_udc *usbssp_data,
bool allocate_completion,
gfp_t mem_flags)
diff --git a/drivers/usb/usbssp/gadget.c b/drivers/usb/usbssp/gadget.c
index 833647600485..bf6a147e2a16 100644
--- a/drivers/usb/usbssp/gadget.c
+++ b/drivers/usb/usbssp/gadget.c
@@ -723,6 +723,81 @@ int usbssp_dequeue(struct usbssp_ep *ep_priv, struct
usbssp_request *req_priv)
return ret;
}
+/* Drop an endpoint from a new bandwidth configuration for this device.
+ * Only one call to this function is allowed per endpoint before
+ * check_bandwidth() or reset_bandwidth() must be called.
+ * A call to usbssp_drop_endpoint() followed by a call to usbssp_add_endpoint()
+ * will add the endpoint to the schedule with possibly new parameters
+ * denoted by a different endpoint descriptor in usbssp_ep.
+ * A call to usbssp_add_endpoint() followed by a call to
+ * usbsssp_drop_endpoint() is not allowed.
+ */
+int usbssp_drop_endpoint(struct usbssp_udc *usbssp_data, struct usb_gadget *g,
+ struct usbssp_ep *dep)
+{
+ struct usbssp_container_ctx *in_ctx, *out_ctx;
+ struct usbssp_input_control_ctx *ctrl_ctx;
+ unsigned int ep_index;
+ struct usbssp_ep_ctx *ep_ctx;
+ u32 drop_flag;
+ u32 new_add_flags, new_drop_flags;
+ int ret;
+
+ ret = usbssp_check_args(usbssp_data, dep, 1, true, __func__);
+ if (ret <= 0)
+ return ret;
+
+ if (usbssp_data->usbssp_state & USBSSP_STATE_DYING)
+ return
Re: [PATCH v6 7/7] arm64: dts: sdm845: Add tsens nodes
On Thu, Jul 12, 2018 at 3:30 AM Doug Anderson wrote:
>
> Hi Matthias,
>
> On Wed, Jul 11, 2018 at 2:51 PM, Matthias Kaehlcke wrote:
> > On Wed, Jul 11, 2018 at 11:44:13AM -0700, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria
> >> wrote:
> >> > SDM845 has two tsens blocks, one with 13 sensors and the other with 8
> >> > sensors. It uses version 2 of the TSENS IP, so use the fallback property
> >> > to
> >> > allow more common code.
> >> >
> >> > Signed-off-by: Amit Kucheria
> >> > ---
> >> > arch/arm64/boot/dts/qcom/sdm845.dtsi | 16
> >> > 1 file changed, 16 insertions(+)
> >> >
> >> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> >> > b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> >> > index cdaabeb..ba2899c 100644
> >> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> >> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> >> > @@ -221,6 +221,22 @@
> >> > #interrupt-cells = <2>;
> >> > };
> >> >
> >> > + tsens0: tsens@c263000 {
> >>
> >> As per my comments in the bindings, nit that this should probably be
> >> "thermal-sensor" not "tsens", AKA:
> >>
> >> tsens0: thermal-sensor@c263000 {
Fixed.
> >> > + compatible = "qcom,sdm845-tsens",
> >> > "qcom,tsens-v2";
> >> > + reg = <0xc263000 0x1ff>, /* TM */
> >> > + <0xc222000 0x1ff>; /* SROT */
> >> > + #qcom,sensors = <13>;
> >>
> >> As per my comment in the bindings and the code, I'm confused about the
> >> whole "#qcom,sensors" bit. It's not documented and doesn't seem
> >> hooked up in the code either.
> >>
> >> ...but if people have tested this, perhaps I'm confused. How can
> >> things work if num_sensors is 0???
> >
> > The mystery is resolved by:
> >
> > commit 6d7c70d1cd6526dc79e3d3b3faae1c40c1681168
> > Author: Bjorn Andersson
> > Date: Mon May 7 16:53:39 2018 -0700
> >
> > thermal: qcom: tsens: Allow number of sensors to come from DT
> >
> > For platforms that has multiple copies of the TSENS hardware block it's
> > necessary to be able to specify the number of sensors per block in
> > DeviceTree.
> >
> > Signed-off-by: Bjorn Andersson
> > Reviewed-by: Amit Kucheria
> > Reviewed-by: Rob Herring
> > Signed-off-by: Eduardo Valentin
> >
> >
> > I bumped into this during testing ;-)
I think this was merged in 4.17, so you didn't see it in your tree :-)
> Ah, now it makes sense to me! Serves me right for assuming it would
> be in the same series and not checking if it was something that had
> already landed. Thanks. Please ignore the parts of my comments
> related to the "#qcom,sensors" property. I guess Rob must have
> thought that the "#" in the name was fine and he's the one in charge
> not me.
Thanks for your review, Doug. I'll test this and post a v7 today. I'd
really like to get this accepted for 4.19 so I can post interrupt
support and some more cleanups.
Regards,
Amit
Re: [PATCH v6 7/7] arm64: dts: sdm845: Add tsens nodes
On Thu, Jul 12, 2018 at 3:30 AM Doug Anderson wrote:
>
> Hi Matthias,
>
> On Wed, Jul 11, 2018 at 2:51 PM, Matthias Kaehlcke wrote:
> > On Wed, Jul 11, 2018 at 11:44:13AM -0700, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria
> >> wrote:
> >> > SDM845 has two tsens blocks, one with 13 sensors and the other with 8
> >> > sensors. It uses version 2 of the TSENS IP, so use the fallback property
> >> > to
> >> > allow more common code.
> >> >
> >> > Signed-off-by: Amit Kucheria
> >> > ---
> >> > arch/arm64/boot/dts/qcom/sdm845.dtsi | 16
> >> > 1 file changed, 16 insertions(+)
> >> >
> >> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> >> > b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> >> > index cdaabeb..ba2899c 100644
> >> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> >> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> >> > @@ -221,6 +221,22 @@
> >> > #interrupt-cells = <2>;
> >> > };
> >> >
> >> > + tsens0: tsens@c263000 {
> >>
> >> As per my comments in the bindings, nit that this should probably be
> >> "thermal-sensor" not "tsens", AKA:
> >>
> >> tsens0: thermal-sensor@c263000 {
Fixed.
> >> > + compatible = "qcom,sdm845-tsens",
> >> > "qcom,tsens-v2";
> >> > + reg = <0xc263000 0x1ff>, /* TM */
> >> > + <0xc222000 0x1ff>; /* SROT */
> >> > + #qcom,sensors = <13>;
> >>
> >> As per my comment in the bindings and the code, I'm confused about the
> >> whole "#qcom,sensors" bit. It's not documented and doesn't seem
> >> hooked up in the code either.
> >>
> >> ...but if people have tested this, perhaps I'm confused. How can
> >> things work if num_sensors is 0???
> >
> > The mystery is resolved by:
> >
> > commit 6d7c70d1cd6526dc79e3d3b3faae1c40c1681168
> > Author: Bjorn Andersson
> > Date: Mon May 7 16:53:39 2018 -0700
> >
> > thermal: qcom: tsens: Allow number of sensors to come from DT
> >
> > For platforms that has multiple copies of the TSENS hardware block it's
> > necessary to be able to specify the number of sensors per block in
> > DeviceTree.
> >
> > Signed-off-by: Bjorn Andersson
> > Reviewed-by: Amit Kucheria
> > Reviewed-by: Rob Herring
> > Signed-off-by: Eduardo Valentin
> >
> >
> > I bumped into this during testing ;-)
I think this was merged in 4.17, so you didn't see it in your tree :-)
> Ah, now it makes sense to me! Serves me right for assuming it would
> be in the same series and not checking if it was something that had
> already landed. Thanks. Please ignore the parts of my comments
> related to the "#qcom,sensors" property. I guess Rob must have
> thought that the "#" in the name was fine and he's the one in charge
> not me.
Thanks for your review, Doug. I'll test this and post a v7 today. I'd
really like to get this accepted for 4.19 so I can post interrupt
support and some more cleanups.
Regards,
Amit
Re: linux-next: duplicate patches in the gfs2 and xfs trees
Hi Stephen,
On 12 July 2018 at 06:41, Stephen Rothwell wrote:
> Hi Andreas,
>
> On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher
> wrote:
>>
>> this is what I'm seeing (git log --pretty=oneline --abbrev-commit
>> --graph ^origin/master gfs2/for-next):
>>
>> * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize
>> == PAGE_SIZE
>> * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads
>> * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next
>> |\
>> | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support
>> to iomap_readpage_actor
>> | * ec181f6782d8 iomap: support direct I/O to inline data
>> | * 09230435dffd iomap: refactor iomap_dio_actor
>> | * c03cea42149d iomap: add initial support for writes without buffer heads
>> | * 72b4daa24129 iomap: add an iomap-based readpage and readpages
>> implementation
>> * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap
>> * | 2e2834ef1797 GFS2: Fix recovery issues for spectators
>> * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next
>> |\ \
>> | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end}
>> | * | 967bcc91b044 gfs2: iomap direct I/O support
>> | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup
>> | * | 64bc06bb32ee gfs2: iomap buffered write support
>> | * | d505a96a3b16 gfs2: Further iomap cleanups
>> | |/
>> | * e184fde6f3f5 iomap: add private pointer to struct iomap
>> | * 63899c6f8851 iomap: add a page_done callback
>> | * 19e0c58f6552 iomap: generic inline data handling
>> | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously
>> | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new
>> | * a6d639da63ae fs: factor out a __generic_write_end helper
>> * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t
>> * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of posix_acl_to_xattr
>> * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have
>> blocks reserved
>> * d1475c07f7ce GFS2: rgrp free blocks used incorrectly
>> * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd
>> * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code
>> * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly
>> * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole
>> * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock
>> * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes
>>
>> Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on
>> xfs/iomap-4.19-merge. That was my initial merge from
>> xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge
>> commit. I've then merged our iomap-write branch into for-next, with
>> two additional commits on top. Then comes the rest of
>> xfs/iomap-4.19-merge (that branch has moved ahead in the meantime),
>> again with two more commits on top.
>>
>> There are no rebased commits, you're looking at the exact same commits.
>
> The problem is that commits
>
> a6d639da63ae fs: factor out a __generic_write_end helper
>
> to
>
> 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support
>
> have been rebased in the xfs tree from a base of v4.18-rc1 to
> v4.18-rc4, so that those patches now appear twice in linux-next where I
> have merged the gfs2 tree and the xfs tree.
Ah, I see now. It's xfs/for-next that contains those rebased commits
from xfs/iomap-4.19-merge.
> This has caused a few
> conflicts today as there are more changes to the same files affected by
> those commits in the xfs tree. to iomap_readpage_actor
>
> What should have happened is that those commits should not have been
> rebased, so either the xfs tree needs rebuilding to use the old
> commits, or your tree needs to be rebuilt using the new commits from
> the xfs tree. This is why we do not like the rebasing of published
> trees (especially when a subset of the tree is shared with other
> developers).
>
> Also, if you are going to merge (part of) another tree you need to make
> sure that the other maintainer will not do a rebase of it (I assume
> that this was probably talked about).
Indeed, the idea of setting up xfs/iomap-4.19-merge was to have a
common base that xfs/for-next and gfs2/for-next could both merge from.
Darrick, could you please fix xfs/for-next?
Thanks a lot,
Andreas
Re: linux-next: duplicate patches in the gfs2 and xfs trees
Hi Stephen,
On 12 July 2018 at 06:41, Stephen Rothwell wrote:
> Hi Andreas,
>
> On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher
> wrote:
>>
>> this is what I'm seeing (git log --pretty=oneline --abbrev-commit
>> --graph ^origin/master gfs2/for-next):
>>
>> * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize
>> == PAGE_SIZE
>> * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads
>> * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next
>> |\
>> | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support
>> to iomap_readpage_actor
>> | * ec181f6782d8 iomap: support direct I/O to inline data
>> | * 09230435dffd iomap: refactor iomap_dio_actor
>> | * c03cea42149d iomap: add initial support for writes without buffer heads
>> | * 72b4daa24129 iomap: add an iomap-based readpage and readpages
>> implementation
>> * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap
>> * | 2e2834ef1797 GFS2: Fix recovery issues for spectators
>> * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next
>> |\ \
>> | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end}
>> | * | 967bcc91b044 gfs2: iomap direct I/O support
>> | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup
>> | * | 64bc06bb32ee gfs2: iomap buffered write support
>> | * | d505a96a3b16 gfs2: Further iomap cleanups
>> | |/
>> | * e184fde6f3f5 iomap: add private pointer to struct iomap
>> | * 63899c6f8851 iomap: add a page_done callback
>> | * 19e0c58f6552 iomap: generic inline data handling
>> | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously
>> | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new
>> | * a6d639da63ae fs: factor out a __generic_write_end helper
>> * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t
>> * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of posix_acl_to_xattr
>> * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have
>> blocks reserved
>> * d1475c07f7ce GFS2: rgrp free blocks used incorrectly
>> * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd
>> * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code
>> * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly
>> * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole
>> * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock
>> * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes
>>
>> Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on
>> xfs/iomap-4.19-merge. That was my initial merge from
>> xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge
>> commit. I've then merged our iomap-write branch into for-next, with
>> two additional commits on top. Then comes the rest of
>> xfs/iomap-4.19-merge (that branch has moved ahead in the meantime),
>> again with two more commits on top.
>>
>> There are no rebased commits, you're looking at the exact same commits.
>
> The problem is that commits
>
> a6d639da63ae fs: factor out a __generic_write_end helper
>
> to
>
> 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support
>
> have been rebased in the xfs tree from a base of v4.18-rc1 to
> v4.18-rc4, so that those patches now appear twice in linux-next where I
> have merged the gfs2 tree and the xfs tree.
Ah, I see now. It's xfs/for-next that contains those rebased commits
from xfs/iomap-4.19-merge.
> This has caused a few
> conflicts today as there are more changes to the same files affected by
> those commits in the xfs tree. to iomap_readpage_actor
>
> What should have happened is that those commits should not have been
> rebased, so either the xfs tree needs rebuilding to use the old
> commits, or your tree needs to be rebuilt using the new commits from
> the xfs tree. This is why we do not like the rebasing of published
> trees (especially when a subset of the tree is shared with other
> developers).
>
> Also, if you are going to merge (part of) another tree you need to make
> sure that the other maintainer will not do a rebase of it (I assume
> that this was probably talked about).
Indeed, the idea of setting up xfs/iomap-4.19-merge was to have a
common base that xfs/for-next and gfs2/for-next could both merge from.
Darrick, could you please fix xfs/for-next?
Thanks a lot,
Andreas
Re: [PATCH v6 5/7] thermal: tsens: Add generic support for TSENS v2 IP
On Thu, Jul 12, 2018 at 12:10 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria
> wrote:
> > SDM845 uses v2 of the TSENS IP block but the get_temp() function
> > appears to be identical across v2.x.y in code seen so far. We use the
> > generic get_temp() function defined as part of ops_generic_v2.
> >
> > Signed-off-by: Amit Kucheria
> > ---
> > drivers/thermal/qcom/tsens-v2.c | 6 +-
> > drivers/thermal/qcom/tsens.c| 3 +++
> > drivers/thermal/qcom/tsens.h| 5 -
> > 3 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/qcom/tsens-v2.c
> > b/drivers/thermal/qcom/tsens-v2.c
> > index 34ba6c7..f40150f 100644
> > --- a/drivers/thermal/qcom/tsens-v2.c
> > +++ b/drivers/thermal/qcom/tsens-v2.c
> > @@ -69,8 +69,12 @@ static const struct tsens_ops ops_generic_v2 = {
> > .get_temp = get_temp_tsens_v2,
> > };
> >
> > +const struct tsens_data data_tsens_v2 = {
> > + .ops= _generic_v2,
> > +};
> > +
> > +/* Kept around for backward compatibility with old msm8996.dtsi */
> > const struct tsens_data data_8996 = {
> > .num_sensors= 13,
> > .ops= _generic_v2,
> > };
>
> Something seems fishy here. You have a ".num_sensors" for sdm8996
> hardcoded to 13 but you don't have a ".num_sensors" for your new v2.
> Where does num_sensors get set for everyone else? In patch #3 you
> have a new "#qcom,sensors" but:
>
> 1. Nothing reads this as far as I can tell, so that means everyone
> will end up with 0 sensors.
>
> 2. On your 2nd block of sensors in the sdm8996 device tree (see
> earlier patch in the series) you try to set qcom,sensors to 8. ...but
> since you still have a compatible of "qcom,msm8996-tsens" you'll get
> 13. That seems wrong. ...or did I miss something?
Refer to commit 6d7c70d1cd6 (thermal: qcom: tsens: Allow number of
sensors to come from DT) merged earlier. #qcom,sensors will override
the platform data if defined.
Re: [PATCH v6 5/7] thermal: tsens: Add generic support for TSENS v2 IP
On Thu, Jul 12, 2018 at 12:10 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria
> wrote:
> > SDM845 uses v2 of the TSENS IP block but the get_temp() function
> > appears to be identical across v2.x.y in code seen so far. We use the
> > generic get_temp() function defined as part of ops_generic_v2.
> >
> > Signed-off-by: Amit Kucheria
> > ---
> > drivers/thermal/qcom/tsens-v2.c | 6 +-
> > drivers/thermal/qcom/tsens.c| 3 +++
> > drivers/thermal/qcom/tsens.h| 5 -
> > 3 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/qcom/tsens-v2.c
> > b/drivers/thermal/qcom/tsens-v2.c
> > index 34ba6c7..f40150f 100644
> > --- a/drivers/thermal/qcom/tsens-v2.c
> > +++ b/drivers/thermal/qcom/tsens-v2.c
> > @@ -69,8 +69,12 @@ static const struct tsens_ops ops_generic_v2 = {
> > .get_temp = get_temp_tsens_v2,
> > };
> >
> > +const struct tsens_data data_tsens_v2 = {
> > + .ops= _generic_v2,
> > +};
> > +
> > +/* Kept around for backward compatibility with old msm8996.dtsi */
> > const struct tsens_data data_8996 = {
> > .num_sensors= 13,
> > .ops= _generic_v2,
> > };
>
> Something seems fishy here. You have a ".num_sensors" for sdm8996
> hardcoded to 13 but you don't have a ".num_sensors" for your new v2.
> Where does num_sensors get set for everyone else? In patch #3 you
> have a new "#qcom,sensors" but:
>
> 1. Nothing reads this as far as I can tell, so that means everyone
> will end up with 0 sensors.
>
> 2. On your 2nd block of sensors in the sdm8996 device tree (see
> earlier patch in the series) you try to set qcom,sensors to 8. ...but
> since you still have a compatible of "qcom,msm8996-tsens" you'll get
> 13. That seems wrong. ...or did I miss something?
Refer to commit 6d7c70d1cd6 (thermal: qcom: tsens: Allow number of
sensors to come from DT) merged earlier. #qcom,sensors will override
the platform data if defined.
[PATCH v4 2/4] rtc: OMAP: Add support for rtc-only mode
Prepare rtc driver for rtc-only with DDR in self-refresh mode.
omap_rtc_power_off now should cater to two features:
1) RTC plus DDR in self-refresh is power a saving mode where in the
entire system including the different voltage rails from PMIC are
shutdown except the ones feeding on to RTC and DDR. DDR is kept in
self-refresh hence the contents are preserved. RTC ALARM2 is connected
to PMIC_EN line once we the ALARM2 is triggered we enter the mode with
DDR in self-refresh and RTC Ticking. After a predetermined time an RTC
ALARM1 triggers waking up the system[1]. The control goes to bootloader.
The bootloader then checks RTC scratchpad registers to confirm it was an
rtc_only wakeup and follows a different path, configure bare minimal
clocks for ddr and then jumps to the resume address in another RTC
scratchpad registers and transfers the control to Kernel. Kernel then
restores the saved context. omap_rtc_power_off_program does the ALARM2
programming part.
[1] http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf Page 2884
2) Power-off: This is usual poweroff mode. omap_rtc_power_off calls the
above omap_rtc_power_off_program function and in addition to that
programs the OMAP_RTC_PMIC_REG for any external wake ups for PMIC like
the pushbutton and shuts off the PMIC.
Hence the split in omap_rtc_power_off.
Signed-off-by: Keerthy
---
drivers/rtc/rtc-omap.c | 53 --
1 file changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 88da927..cb19ece 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -415,21 +415,12 @@ static int omap_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alm)
static struct omap_rtc *omap_rtc_power_off_rtc;
-/*
- * omap_rtc_poweroff: RTC-controlled power off
- *
- * The RTC can be used to control an external PMIC via the pmic_power_en pin,
- * which can be configured to transition to OFF on ALARM2 events.
- *
- * Notes:
- * The two-second alarm offset is the shortest offset possible as the alarm
- * registers must be set before the next timer update and the offset
- * calculation is too heavy for everything to be done within a single access
- * period (~15 us).
- *
- * Called with local interrupts disabled.
+/**
+ * omap_rtc_power_off_program: Set the pmic power off sequence. The RTC
+ * generates pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
*/
-static void omap_rtc_power_off(void)
+static int omap_rtc_power_off_program(struct device *dev)
{
struct omap_rtc *rtc = omap_rtc_power_off_rtc;
struct rtc_time tm;
@@ -456,7 +447,7 @@ static void omap_rtc_power_off(void)
if (tm2bcd() < 0) {
dev_err(>rtc->dev, "power off failed\n");
rtc->type->lock(rtc);
- return;
+ return -EINVAL;
}
rtc_wait_not_busy(rtc);
@@ -481,6 +472,38 @@ static void omap_rtc_power_off(void)
goto again;
rtc->type->lock(rtc);
+ return 0;
+}
+
+/*
+ * omap_rtc_poweroff: RTC-controlled power off
+ *
+ * The RTC can be used to control an external PMIC via the pmic_power_en pin,
+ * which can be configured to transition to OFF on ALARM2 events.
+ *
+ * Notes:
+ * The one-second alarm offset is the shortest offset possible as the alarm
+ * registers must be set before the next timer update and the offset
+ * calculation is too heavy for everything to be done within a single access
+ * period (~15 us).
+ *
+ * Called with local interrupts disabled.
+ */
+static void omap_rtc_power_off(void)
+{
+ struct rtc_device *rtc = omap_rtc_power_off_rtc->rtc;
+ u32 val;
+
+ omap_rtc_power_off_program(rtc->dev.parent);
+
+ /* Set PMIC power enable and EXT_WAKEUP in case PB power on is used */
+ omap_rtc_power_off_rtc->type->unlock(omap_rtc_power_off_rtc);
+ val = rtc_readl(omap_rtc_power_off_rtc, OMAP_RTC_PMIC_REG);
+ val |= OMAP_RTC_PMIC_POWER_EN_EN | OMAP_RTC_PMIC_EXT_WKUP_POL(0) |
+ OMAP_RTC_PMIC_EXT_WKUP_EN(0);
+ rtc_writel(omap_rtc_power_off_rtc, OMAP_RTC_PMIC_REG, val);
+ omap_rtc_power_off_rtc->type->lock(omap_rtc_power_off_rtc);
+
/*
* Wait for alarm to trigger (within two seconds) and external PMIC to
* power off the system. Add a 500 ms margin for external latencies
--
1.9.1
[PATCH v4 2/4] rtc: OMAP: Add support for rtc-only mode
Prepare rtc driver for rtc-only with DDR in self-refresh mode.
omap_rtc_power_off now should cater to two features:
1) RTC plus DDR in self-refresh is power a saving mode where in the
entire system including the different voltage rails from PMIC are
shutdown except the ones feeding on to RTC and DDR. DDR is kept in
self-refresh hence the contents are preserved. RTC ALARM2 is connected
to PMIC_EN line once we the ALARM2 is triggered we enter the mode with
DDR in self-refresh and RTC Ticking. After a predetermined time an RTC
ALARM1 triggers waking up the system[1]. The control goes to bootloader.
The bootloader then checks RTC scratchpad registers to confirm it was an
rtc_only wakeup and follows a different path, configure bare minimal
clocks for ddr and then jumps to the resume address in another RTC
scratchpad registers and transfers the control to Kernel. Kernel then
restores the saved context. omap_rtc_power_off_program does the ALARM2
programming part.
[1] http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf Page 2884
2) Power-off: This is usual poweroff mode. omap_rtc_power_off calls the
above omap_rtc_power_off_program function and in addition to that
programs the OMAP_RTC_PMIC_REG for any external wake ups for PMIC like
the pushbutton and shuts off the PMIC.
Hence the split in omap_rtc_power_off.
Signed-off-by: Keerthy
---
drivers/rtc/rtc-omap.c | 53 --
1 file changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 88da927..cb19ece 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -415,21 +415,12 @@ static int omap_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alm)
static struct omap_rtc *omap_rtc_power_off_rtc;
-/*
- * omap_rtc_poweroff: RTC-controlled power off
- *
- * The RTC can be used to control an external PMIC via the pmic_power_en pin,
- * which can be configured to transition to OFF on ALARM2 events.
- *
- * Notes:
- * The two-second alarm offset is the shortest offset possible as the alarm
- * registers must be set before the next timer update and the offset
- * calculation is too heavy for everything to be done within a single access
- * period (~15 us).
- *
- * Called with local interrupts disabled.
+/**
+ * omap_rtc_power_off_program: Set the pmic power off sequence. The RTC
+ * generates pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
*/
-static void omap_rtc_power_off(void)
+static int omap_rtc_power_off_program(struct device *dev)
{
struct omap_rtc *rtc = omap_rtc_power_off_rtc;
struct rtc_time tm;
@@ -456,7 +447,7 @@ static void omap_rtc_power_off(void)
if (tm2bcd() < 0) {
dev_err(>rtc->dev, "power off failed\n");
rtc->type->lock(rtc);
- return;
+ return -EINVAL;
}
rtc_wait_not_busy(rtc);
@@ -481,6 +472,38 @@ static void omap_rtc_power_off(void)
goto again;
rtc->type->lock(rtc);
+ return 0;
+}
+
+/*
+ * omap_rtc_poweroff: RTC-controlled power off
+ *
+ * The RTC can be used to control an external PMIC via the pmic_power_en pin,
+ * which can be configured to transition to OFF on ALARM2 events.
+ *
+ * Notes:
+ * The one-second alarm offset is the shortest offset possible as the alarm
+ * registers must be set before the next timer update and the offset
+ * calculation is too heavy for everything to be done within a single access
+ * period (~15 us).
+ *
+ * Called with local interrupts disabled.
+ */
+static void omap_rtc_power_off(void)
+{
+ struct rtc_device *rtc = omap_rtc_power_off_rtc->rtc;
+ u32 val;
+
+ omap_rtc_power_off_program(rtc->dev.parent);
+
+ /* Set PMIC power enable and EXT_WAKEUP in case PB power on is used */
+ omap_rtc_power_off_rtc->type->unlock(omap_rtc_power_off_rtc);
+ val = rtc_readl(omap_rtc_power_off_rtc, OMAP_RTC_PMIC_REG);
+ val |= OMAP_RTC_PMIC_POWER_EN_EN | OMAP_RTC_PMIC_EXT_WKUP_POL(0) |
+ OMAP_RTC_PMIC_EXT_WKUP_EN(0);
+ rtc_writel(omap_rtc_power_off_rtc, OMAP_RTC_PMIC_REG, val);
+ omap_rtc_power_off_rtc->type->lock(omap_rtc_power_off_rtc);
+
/*
* Wait for alarm to trigger (within two seconds) and external PMIC to
* power off the system. Add a 500 ms margin for external latencies
--
1.9.1
[PATCH v4 0/4] rtc: OMAP: Add support for rtc-only mode
Prepare rtc driver for rtc-only with DDR in self-refresh mode. The patch series is based on top of Johan Hovald's series: https://lkml.kernel.org/r/20180704090558.16647-1-jo...@kernel.org Tested for suspend/resume and poweroff on am437x-gp-evm. Keerthy (4): rtc: omap: Cut down the shutdown time from 2 seconds to 1 sec rtc: OMAP: Add support for rtc-only mode rtc: omap: use of_device_is_system_power_controller function rtc: interface: Add power_off_program to rtc_class_ops drivers/rtc/interface.c | 12 + drivers/rtc/rtc-omap.c | 70 +++-- include/linux/rtc.h | 2 ++ 3 files changed, 65 insertions(+), 19 deletions(-) -- 1.9.1
[PATCH v4 4/4] rtc: interface: Add power_off_program to rtc_class_ops
Add an interface function to set up the rtc for a power_off
mode.
Signed-off-by: Keerthy
---
drivers/rtc/interface.c | 12
drivers/rtc/rtc-omap.c | 1 +
include/linux/rtc.h | 2 ++
3 files changed, 15 insertions(+)
diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 6d4012d..c19668b9 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -1139,3 +1139,15 @@ int rtc_set_offset(struct rtc_device *rtc, long offset)
trace_rtc_set_offset(offset, ret);
return ret;
}
+
+/**
+ * rtc_power_off_program - Some of the rtc are hooked on to PMIC_EN
+ * line and can be used to power off the SoC.
+ *
+ * Kernel interface to program rtc to power off
+ */
+int rtc_power_off_program(struct rtc_device *rtc)
+{
+ return rtc->ops->power_off_program(rtc->dev.parent);
+}
+EXPORT_SYMBOL_GPL(rtc_power_off_program);
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 3610efd..9c9ea44 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -518,6 +518,7 @@ static void omap_rtc_power_off(void)
.read_alarm = omap_rtc_read_alarm,
.set_alarm = omap_rtc_set_alarm,
.alarm_irq_enable = omap_rtc_alarm_irq_enable,
+ .power_off_program = omap_rtc_power_off_program,
};
static const struct omap_rtc_device_type omap_rtc_default_type = {
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 6268208..3fc640c 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -85,6 +85,7 @@ struct rtc_class_ops {
int (*alarm_irq_enable)(struct device *, unsigned int enabled);
int (*read_offset)(struct device *, long *offset);
int (*set_offset)(struct device *, long offset);
+ int (*power_off_program)(struct device *dev);
};
typedef struct rtc_task {
@@ -229,6 +230,7 @@ int rtc_timer_start(struct rtc_device *rtc, struct
rtc_timer *timer,
int rtc_read_offset(struct rtc_device *rtc, long *offset);
int rtc_set_offset(struct rtc_device *rtc, long offset);
void rtc_timer_do_work(struct work_struct *work);
+int rtc_power_off_program(struct rtc_device *rtc);
static inline bool is_leap_year(unsigned int year)
{
--
1.9.1
[PATCH v4 3/4] rtc: omap: use of_device_is_system_power_controller function
Use of_device_is_system_power_controller instead of manually reading
the system-power-controller property from the device tree node.
Signed-off-by: Keerthy
---
drivers/rtc/rtc-omap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index cb19ece..3610efd 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -753,8 +753,7 @@ static int omap_rtc_probe(struct platform_device *pdev)
if (of_id) {
rtc->type = of_id->data;
rtc->is_pmic_controller = rtc->type->has_pmic_mode &&
- of_property_read_bool(pdev->dev.of_node,
- "system-power-controller");
+ of_device_is_system_power_controller(pdev->dev.of_node);
} else {
id_entry = platform_get_device_id(pdev);
rtc->type = (void *)id_entry->driver_data;
--
1.9.1
[PATCH v4 0/4] rtc: OMAP: Add support for rtc-only mode
Prepare rtc driver for rtc-only with DDR in self-refresh mode. The patch series is based on top of Johan Hovald's series: https://lkml.kernel.org/r/20180704090558.16647-1-jo...@kernel.org Tested for suspend/resume and poweroff on am437x-gp-evm. Keerthy (4): rtc: omap: Cut down the shutdown time from 2 seconds to 1 sec rtc: OMAP: Add support for rtc-only mode rtc: omap: use of_device_is_system_power_controller function rtc: interface: Add power_off_program to rtc_class_ops drivers/rtc/interface.c | 12 + drivers/rtc/rtc-omap.c | 70 +++-- include/linux/rtc.h | 2 ++ 3 files changed, 65 insertions(+), 19 deletions(-) -- 1.9.1
[PATCH v4 4/4] rtc: interface: Add power_off_program to rtc_class_ops
Add an interface function to set up the rtc for a power_off
mode.
Signed-off-by: Keerthy
---
drivers/rtc/interface.c | 12
drivers/rtc/rtc-omap.c | 1 +
include/linux/rtc.h | 2 ++
3 files changed, 15 insertions(+)
diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 6d4012d..c19668b9 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -1139,3 +1139,15 @@ int rtc_set_offset(struct rtc_device *rtc, long offset)
trace_rtc_set_offset(offset, ret);
return ret;
}
+
+/**
+ * rtc_power_off_program - Some of the rtc are hooked on to PMIC_EN
+ * line and can be used to power off the SoC.
+ *
+ * Kernel interface to program rtc to power off
+ */
+int rtc_power_off_program(struct rtc_device *rtc)
+{
+ return rtc->ops->power_off_program(rtc->dev.parent);
+}
+EXPORT_SYMBOL_GPL(rtc_power_off_program);
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 3610efd..9c9ea44 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -518,6 +518,7 @@ static void omap_rtc_power_off(void)
.read_alarm = omap_rtc_read_alarm,
.set_alarm = omap_rtc_set_alarm,
.alarm_irq_enable = omap_rtc_alarm_irq_enable,
+ .power_off_program = omap_rtc_power_off_program,
};
static const struct omap_rtc_device_type omap_rtc_default_type = {
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 6268208..3fc640c 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -85,6 +85,7 @@ struct rtc_class_ops {
int (*alarm_irq_enable)(struct device *, unsigned int enabled);
int (*read_offset)(struct device *, long *offset);
int (*set_offset)(struct device *, long offset);
+ int (*power_off_program)(struct device *dev);
};
typedef struct rtc_task {
@@ -229,6 +230,7 @@ int rtc_timer_start(struct rtc_device *rtc, struct
rtc_timer *timer,
int rtc_read_offset(struct rtc_device *rtc, long *offset);
int rtc_set_offset(struct rtc_device *rtc, long offset);
void rtc_timer_do_work(struct work_struct *work);
+int rtc_power_off_program(struct rtc_device *rtc);
static inline bool is_leap_year(unsigned int year)
{
--
1.9.1
[PATCH v4 3/4] rtc: omap: use of_device_is_system_power_controller function
Use of_device_is_system_power_controller instead of manually reading
the system-power-controller property from the device tree node.
Signed-off-by: Keerthy
---
drivers/rtc/rtc-omap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index cb19ece..3610efd 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -753,8 +753,7 @@ static int omap_rtc_probe(struct platform_device *pdev)
if (of_id) {
rtc->type = of_id->data;
rtc->is_pmic_controller = rtc->type->has_pmic_mode &&
- of_property_read_bool(pdev->dev.of_node,
- "system-power-controller");
+ of_device_is_system_power_controller(pdev->dev.of_node);
} else {
id_entry = platform_get_device_id(pdev);
rtc->type = (void *)id_entry->driver_data;
--
1.9.1
[PATCH v4 1/4] rtc: omap: Cut down the shutdown time from 2 seconds to 1 sec
Cut down the shutdown time from 2 seconds to 1 sec. In case of roll
over try again.
Signed-off-by: Keerthy
---
Changes in v4:
* Fixed a compilation issue.
* Extended the roll over check post interrupt programming.
drivers/rtc/rtc-omap.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 323ff55..88da927 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -435,17 +435,23 @@ static void omap_rtc_power_off(void)
struct rtc_time tm;
unsigned long now;
u32 val;
+ int seconds;
rtc->type->unlock(rtc);
/* enable pmic_power_en control */
val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
- /* set alarm two seconds from now */
+again:
+ /* Clear any existing ALARM2 event */
+ rtc_writel(rtc, OMAP_RTC_STATUS_REG, OMAP_RTC_STATUS_ALARM2);
+
+ /* set alarm one second from now */
omap_rtc_read_time_raw(rtc, );
+ seconds = tm.tm_sec;
bcd2tm();
rtc_tm_to_time(, );
- rtc_time_to_tm(now + 2, );
+ rtc_time_to_tm(now + 1, );
if (tm2bcd() < 0) {
dev_err(>rtc->dev, "power off failed\n");
@@ -470,6 +476,9 @@ static void omap_rtc_power_off(void)
val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
+ /* Our calculations started right before the rollover, try again */
+ if (seconds != rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_SECONDS_REG))
+ goto again;
rtc->type->lock(rtc);
/*
--
1.9.1
[PATCH v4 1/4] rtc: omap: Cut down the shutdown time from 2 seconds to 1 sec
Cut down the shutdown time from 2 seconds to 1 sec. In case of roll
over try again.
Signed-off-by: Keerthy
---
Changes in v4:
* Fixed a compilation issue.
* Extended the roll over check post interrupt programming.
drivers/rtc/rtc-omap.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 323ff55..88da927 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -435,17 +435,23 @@ static void omap_rtc_power_off(void)
struct rtc_time tm;
unsigned long now;
u32 val;
+ int seconds;
rtc->type->unlock(rtc);
/* enable pmic_power_en control */
val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
rtc_writel(rtc, OMAP_RTC_PMIC_REG, val | OMAP_RTC_PMIC_POWER_EN_EN);
- /* set alarm two seconds from now */
+again:
+ /* Clear any existing ALARM2 event */
+ rtc_writel(rtc, OMAP_RTC_STATUS_REG, OMAP_RTC_STATUS_ALARM2);
+
+ /* set alarm one second from now */
omap_rtc_read_time_raw(rtc, );
+ seconds = tm.tm_sec;
bcd2tm();
rtc_tm_to_time(, );
- rtc_time_to_tm(now + 2, );
+ rtc_time_to_tm(now + 1, );
if (tm2bcd() < 0) {
dev_err(>rtc->dev, "power off failed\n");
@@ -470,6 +476,9 @@ static void omap_rtc_power_off(void)
val = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
rtc_writel(rtc, OMAP_RTC_INTERRUPTS_REG,
val | OMAP_RTC_INTERRUPTS_IT_ALARM2);
+ /* Our calculations started right before the rollover, try again */
+ if (seconds != rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_SECONDS_REG))
+ goto again;
rtc->type->lock(rtc);
/*
--
1.9.1
Re: [PATCH v6 3/7] dt: qcom: 8996: thermal: Move to DT initialisation
On Thu, Jul 12, 2018 at 12:09 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria
> wrote:
> > We also split up the regmap address space into two, one for the TM
> > registers, the other for the SROT registers. This was required to deal with
> > different address offsets for the TM and SROT registers across different
> > SoC families.
>
> The splitting into two regions is actually optional and that should
> probably be mentioned in the commit message.
On the contrary, after this refactor, all new platforms with the
v2.x.y TSENS IP should use two regions. The only reason for patch 2 is
that we're stuck with supporting old 8996/8916 DTs. I'd prefer to
phase out support for the old DTs if possible. I don't want to
encourage any new bindings with a single address space.
> > Since tsens-common.c/init_common() currently only registers one address
> > space, the order is important (TM before SROT). This is OK since the code
> > doesn't really use the SROT functionality yet.
>
> Nowhere in the commit message does this say you're also adding a 2nd
> block of thermal sensors. It seems like you should say that
> somewhere.
>
> ...and it should also be obvious in ${SUBJECT}.
Fixed.
> > Signed-off-by: Amit Kucheria
> > ---
> > arch/arm64/boot/dts/qcom/msm8996.dtsi | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > index 8c7f9ca..6c8a857 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > @@ -461,7 +461,17 @@
> >
> > tsens0: thermal-sensor@4a8000 {
> > compatible = "qcom,msm8996-tsens";
> > - reg = <0x4a8000 0x2000>;
> > + reg = <0x4a9000 0x1000>, /* TM */
> > + <0x4a8000 0x1000>; /* SROT */
>
> Note that the unit address is supposed to match the first "reg"
> address, so either these should be reversed or you should update your
> node name. AKA your node name should be this now:
>
> tsens0: thermal-sensor@4a9000
Fixed.
>
> > + #qcom,sensors = <13>;
>
> As per my responses to other patches, " #qcom,sensors" is undocumented
> and doesn't appear to be read by the driver.
This feature was merged earlier. See commit 6d7c70d1cd6526 (thermal:
qcom: tsens: Allow number of sensors to come from DT)
Regards,
Amit
Re: [PATCH v6 3/7] dt: qcom: 8996: thermal: Move to DT initialisation
On Thu, Jul 12, 2018 at 12:09 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria
> wrote:
> > We also split up the regmap address space into two, one for the TM
> > registers, the other for the SROT registers. This was required to deal with
> > different address offsets for the TM and SROT registers across different
> > SoC families.
>
> The splitting into two regions is actually optional and that should
> probably be mentioned in the commit message.
On the contrary, after this refactor, all new platforms with the
v2.x.y TSENS IP should use two regions. The only reason for patch 2 is
that we're stuck with supporting old 8996/8916 DTs. I'd prefer to
phase out support for the old DTs if possible. I don't want to
encourage any new bindings with a single address space.
> > Since tsens-common.c/init_common() currently only registers one address
> > space, the order is important (TM before SROT). This is OK since the code
> > doesn't really use the SROT functionality yet.
>
> Nowhere in the commit message does this say you're also adding a 2nd
> block of thermal sensors. It seems like you should say that
> somewhere.
>
> ...and it should also be obvious in ${SUBJECT}.
Fixed.
> > Signed-off-by: Amit Kucheria
> > ---
> > arch/arm64/boot/dts/qcom/msm8996.dtsi | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > index 8c7f9ca..6c8a857 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > @@ -461,7 +461,17 @@
> >
> > tsens0: thermal-sensor@4a8000 {
> > compatible = "qcom,msm8996-tsens";
> > - reg = <0x4a8000 0x2000>;
> > + reg = <0x4a9000 0x1000>, /* TM */
> > + <0x4a8000 0x1000>; /* SROT */
>
> Note that the unit address is supposed to match the first "reg"
> address, so either these should be reversed or you should update your
> node name. AKA your node name should be this now:
>
> tsens0: thermal-sensor@4a9000
Fixed.
>
> > + #qcom,sensors = <13>;
>
> As per my responses to other patches, " #qcom,sensors" is undocumented
> and doesn't appear to be read by the driver.
This feature was merged earlier. See commit 6d7c70d1cd6526 (thermal:
qcom: tsens: Allow number of sensors to come from DT)
Regards,
Amit
[PATCH v3 1/5] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"
This isn't per-se a real device, it's a pseudo-device that
represents the use of the Aspeed built-in ColdFire to
implement the FSI protocol by bitbanging the GPIOs instead
of doing it from the ARM core.
Thus it's a drop-in replacement for the existing
fsi-master-gpio pseudo-device for use on systems based
on the Aspeed chips. It has most of the same properties,
plus some more needed to operate the coprocessor.
Signed-off-by: Benjamin Herrenschmidt
---
.../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
new file mode 100644
index ..431bf8a423ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
@@ -0,0 +1,36 @@
+Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
+
+
+Required properties:
+ - compatible =
+ "aspeed,ast2400-cf-fsi-master" for an AST2400 based system
+ or
+ "aspeed,ast2500-cf-fsi-master" for an AST2500 based system
+
+ - clock-gpios = ;: GPIO for FSI clock
+ - data-gpios = ; : GPIO for FSI data signal
+ - enable-gpios = ; : GPIO for enable signal
+ - trans-gpios = ;: GPIO for voltage translator enable
+ - mux-gpios = ; : GPIO for pin multiplexing with other
+ functions (eg, external FSI masters)
+ - memory-region = ; : Reference to the reserved memory for
+ the ColdFire. Must be 2M aligned on
+ AST2400 and 1M aligned on AST2500
+ - aspeed,sram = ;: Reference to the SRAM node.
+ - aspeed,cvic = ;: Reference to the CVIC node.
+
+Examples:
+
+fsi-master {
+compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
+
+ clock-gpios = < 0>;
+data-gpios = < 1>;
+enable-gpios = < 2>;
+trans-gpios = < 3>;
+mux-gpios = < 4>;
+
+ memory-region = <_memory>;
+ sram = <>;
+ cvic = <>;
+}
--
2.17.1
[PATCH v3 3/5] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire
The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which is currently unused on OpenPower systems. This adds an alternative to the fsi-master-gpio driver that uses that coprocessor instead of bit banging from the ARM core itself. The end result is about 4 times faster. The firmware for the coprocessor and its source code can be found at https://github.com/ozbenh/cf-fsi and is system specific. Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/Kconfig |9 + drivers/fsi/Makefile |1 + drivers/fsi/cf-fsi-fw.h | 157 +++ drivers/fsi/fsi-master-ast-cf.c | 1438 ++ include/trace/events/fsi_master_ast_cf.h | 150 +++ 5 files changed, 1755 insertions(+) create mode 100644 drivers/fsi/cf-fsi-fw.h create mode 100644 drivers/fsi/fsi-master-ast-cf.c create mode 100644 include/trace/events/fsi_master_ast_cf.h diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig index 322cec393cf2..e0220d1e1357 100644 --- a/drivers/fsi/Kconfig +++ b/drivers/fsi/Kconfig @@ -27,6 +27,15 @@ config FSI_MASTER_HUB allow chaining of FSI links to an arbitrary depth. This allows for a high target device fanout. +config FSI_MASTER_AST_CF + tristate "FSI master based on Aspeed ColdFire coprocessor" + depends on GPIOLIB + depends on GPIO_ASPEED + ---help--- + This option enables a FSI master using the AST2400 and AST2500 GPIO + lines driven by the internal ColdFire coprocessor. This requires + the corresponding machine specific ColdFire firmware to be available. + config FSI_SCOM tristate "SCOM FSI client device driver" ---help--- diff --git a/drivers/fsi/Makefile b/drivers/fsi/Makefile index 75fdc6d8cfc4..62687ec86d2e 100644 --- a/drivers/fsi/Makefile +++ b/drivers/fsi/Makefile @@ -2,6 +2,7 @@ obj-$(CONFIG_FSI) += fsi-core.o obj-$(CONFIG_FSI_MASTER_HUB) += fsi-master-hub.o obj-$(CONFIG_FSI_MASTER_GPIO) += fsi-master-gpio.o +obj-$(CONFIG_FSI_MASTER_AST_CF) += fsi-master-ast-cf.o obj-$(CONFIG_FSI_SCOM) += fsi-scom.o obj-$(CONFIG_FSI_SBEFIFO) += fsi-sbefifo.o obj-$(CONFIG_FSI_OCC) += fsi-occ.o diff --git a/drivers/fsi/cf-fsi-fw.h b/drivers/fsi/cf-fsi-fw.h new file mode 100644 index ..712df0461911 --- /dev/null +++ b/drivers/fsi/cf-fsi-fw.h @@ -0,0 +1,157 @@ +// SPDX-License-Identifier: GPL-2.0+ +#ifndef __CF_FSI_FW_H +#define __CF_FSI_FW_H + +/* + * uCode file layout + * + * ...03ff : m68k exception vectors + * 0400...04ff : Header info & boot config block + * 0500... : Code & stack + */ + +/* + * Header info & boot config area + * + * The Header info is built into the ucode and provide version and + * platform information. + * + * the Boot config needs to be adjusted by the ARM prior to starting + * the ucode if the Command/Status area isn't at 0x32 in CF space + * (ie. beginning of SRAM). + */ + +#define HDR_OFFSET 0x400 + +/* Info: Signature & version */ +#define HDR_SYS_SIG0x00/* 2 bytes system signature */ +#define SYS_SIG_SHARED0x5348 +#define SYS_SIG_SPLIT 0x5350 +#define HDR_FW_VERS0x02/* 2 bytes Major.Minor */ +#define HDR_API_VERS 0x04/* 2 bytes Major.Minor */ +#define API_VERSION_MAJ 2 /* Current version */ +#define API_VERSION_MIN 1 +#define HDR_FW_OPTIONS 0x08/* 4 bytes option flags */ +#define FW_OPTION_TRACE_EN0x0001 /* FW tracing enabled */ +#define FW_OPTION_CONT_CLOCK 0x0002 /* Continuous clocking supported */ +#define HDR_FW_SIZE0x10/* 4 bytes size for combo image */ + +/* Boot Config: Address of Command/Status area */ +#define HDR_CMD_STAT_AREA 0x80/* 4 bytes CF address */ +#define HDR_FW_CONTROL 0x84/* 4 bytes control flags */ +#define FW_CONTROL_CONT_CLOCK 0x0002 /* Continuous clocking enabled */ +#define FW_CONTROL_DUMMY_RD0x0004 /* Extra dummy read (AST2400) */ +#define FW_CONTROL_USE_STOP0x0008 /* Use STOP instructions */ +#define HDR_CLOCK_GPIO_VADDR 0x90/* 2 bytes offset from GPIO base */ +#define HDR_CLOCK_GPIO_DADDR 0x92/* 2 bytes offset from GPIO base */ +#define HDR_DATA_GPIO_VADDR0x94/* 2 bytes offset from GPIO base */ +#define HDR_DATA_GPIO_DADDR0x96/* 2 bytes offset from GPIO base */ +#define HDR_TRANS_GPIO_VADDR 0x98/* 2 bytes offset from GPIO base */ +#define HDR_TRANS_GPIO_DADDR 0x9a/* 2 bytes offset from GPIO base */ +#define HDR_CLOCK_GPIO_BIT 0x9c/* 1 byte bit number */ +#define HDR_DATA_GPIO_BIT 0x9d/* 1 byte bit number */ +#define HDR_TRANS_GPIO_BIT 0x9e/* 1 byte bit number */ + +/* + * Command/Status area layout: Main part + */ + +/* Command/Status register: + * + * +---+ + * | STAT | RLEN | CLEN | CMD | + * | 8 | 8 | 8 | 8 | + *
[PATCH v3 1/5] dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"
This isn't per-se a real device, it's a pseudo-device that
represents the use of the Aspeed built-in ColdFire to
implement the FSI protocol by bitbanging the GPIOs instead
of doing it from the ARM core.
Thus it's a drop-in replacement for the existing
fsi-master-gpio pseudo-device for use on systems based
on the Aspeed chips. It has most of the same properties,
plus some more needed to operate the coprocessor.
Signed-off-by: Benjamin Herrenschmidt
---
.../bindings/fsi/fsi-master-ast-cf.txt| 36 +++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
diff --git a/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
new file mode 100644
index ..431bf8a423ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
@@ -0,0 +1,36 @@
+Device-tree bindings for ColdFire offloaded gpio-based FSI master driver
+
+
+Required properties:
+ - compatible =
+ "aspeed,ast2400-cf-fsi-master" for an AST2400 based system
+ or
+ "aspeed,ast2500-cf-fsi-master" for an AST2500 based system
+
+ - clock-gpios = ;: GPIO for FSI clock
+ - data-gpios = ; : GPIO for FSI data signal
+ - enable-gpios = ; : GPIO for enable signal
+ - trans-gpios = ;: GPIO for voltage translator enable
+ - mux-gpios = ; : GPIO for pin multiplexing with other
+ functions (eg, external FSI masters)
+ - memory-region = ; : Reference to the reserved memory for
+ the ColdFire. Must be 2M aligned on
+ AST2400 and 1M aligned on AST2500
+ - aspeed,sram = ;: Reference to the SRAM node.
+ - aspeed,cvic = ;: Reference to the CVIC node.
+
+Examples:
+
+fsi-master {
+compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
+
+ clock-gpios = < 0>;
+data-gpios = < 1>;
+enable-gpios = < 2>;
+trans-gpios = < 3>;
+mux-gpios = < 4>;
+
+ memory-region = <_memory>;
+ sram = <>;
+ cvic = <>;
+}
--
2.17.1
[PATCH v3 3/5] fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire
The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which is currently unused on OpenPower systems. This adds an alternative to the fsi-master-gpio driver that uses that coprocessor instead of bit banging from the ARM core itself. The end result is about 4 times faster. The firmware for the coprocessor and its source code can be found at https://github.com/ozbenh/cf-fsi and is system specific. Signed-off-by: Benjamin Herrenschmidt --- drivers/fsi/Kconfig |9 + drivers/fsi/Makefile |1 + drivers/fsi/cf-fsi-fw.h | 157 +++ drivers/fsi/fsi-master-ast-cf.c | 1438 ++ include/trace/events/fsi_master_ast_cf.h | 150 +++ 5 files changed, 1755 insertions(+) create mode 100644 drivers/fsi/cf-fsi-fw.h create mode 100644 drivers/fsi/fsi-master-ast-cf.c create mode 100644 include/trace/events/fsi_master_ast_cf.h diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig index 322cec393cf2..e0220d1e1357 100644 --- a/drivers/fsi/Kconfig +++ b/drivers/fsi/Kconfig @@ -27,6 +27,15 @@ config FSI_MASTER_HUB allow chaining of FSI links to an arbitrary depth. This allows for a high target device fanout. +config FSI_MASTER_AST_CF + tristate "FSI master based on Aspeed ColdFire coprocessor" + depends on GPIOLIB + depends on GPIO_ASPEED + ---help--- + This option enables a FSI master using the AST2400 and AST2500 GPIO + lines driven by the internal ColdFire coprocessor. This requires + the corresponding machine specific ColdFire firmware to be available. + config FSI_SCOM tristate "SCOM FSI client device driver" ---help--- diff --git a/drivers/fsi/Makefile b/drivers/fsi/Makefile index 75fdc6d8cfc4..62687ec86d2e 100644 --- a/drivers/fsi/Makefile +++ b/drivers/fsi/Makefile @@ -2,6 +2,7 @@ obj-$(CONFIG_FSI) += fsi-core.o obj-$(CONFIG_FSI_MASTER_HUB) += fsi-master-hub.o obj-$(CONFIG_FSI_MASTER_GPIO) += fsi-master-gpio.o +obj-$(CONFIG_FSI_MASTER_AST_CF) += fsi-master-ast-cf.o obj-$(CONFIG_FSI_SCOM) += fsi-scom.o obj-$(CONFIG_FSI_SBEFIFO) += fsi-sbefifo.o obj-$(CONFIG_FSI_OCC) += fsi-occ.o diff --git a/drivers/fsi/cf-fsi-fw.h b/drivers/fsi/cf-fsi-fw.h new file mode 100644 index ..712df0461911 --- /dev/null +++ b/drivers/fsi/cf-fsi-fw.h @@ -0,0 +1,157 @@ +// SPDX-License-Identifier: GPL-2.0+ +#ifndef __CF_FSI_FW_H +#define __CF_FSI_FW_H + +/* + * uCode file layout + * + * ...03ff : m68k exception vectors + * 0400...04ff : Header info & boot config block + * 0500... : Code & stack + */ + +/* + * Header info & boot config area + * + * The Header info is built into the ucode and provide version and + * platform information. + * + * the Boot config needs to be adjusted by the ARM prior to starting + * the ucode if the Command/Status area isn't at 0x32 in CF space + * (ie. beginning of SRAM). + */ + +#define HDR_OFFSET 0x400 + +/* Info: Signature & version */ +#define HDR_SYS_SIG0x00/* 2 bytes system signature */ +#define SYS_SIG_SHARED0x5348 +#define SYS_SIG_SPLIT 0x5350 +#define HDR_FW_VERS0x02/* 2 bytes Major.Minor */ +#define HDR_API_VERS 0x04/* 2 bytes Major.Minor */ +#define API_VERSION_MAJ 2 /* Current version */ +#define API_VERSION_MIN 1 +#define HDR_FW_OPTIONS 0x08/* 4 bytes option flags */ +#define FW_OPTION_TRACE_EN0x0001 /* FW tracing enabled */ +#define FW_OPTION_CONT_CLOCK 0x0002 /* Continuous clocking supported */ +#define HDR_FW_SIZE0x10/* 4 bytes size for combo image */ + +/* Boot Config: Address of Command/Status area */ +#define HDR_CMD_STAT_AREA 0x80/* 4 bytes CF address */ +#define HDR_FW_CONTROL 0x84/* 4 bytes control flags */ +#define FW_CONTROL_CONT_CLOCK 0x0002 /* Continuous clocking enabled */ +#define FW_CONTROL_DUMMY_RD0x0004 /* Extra dummy read (AST2400) */ +#define FW_CONTROL_USE_STOP0x0008 /* Use STOP instructions */ +#define HDR_CLOCK_GPIO_VADDR 0x90/* 2 bytes offset from GPIO base */ +#define HDR_CLOCK_GPIO_DADDR 0x92/* 2 bytes offset from GPIO base */ +#define HDR_DATA_GPIO_VADDR0x94/* 2 bytes offset from GPIO base */ +#define HDR_DATA_GPIO_DADDR0x96/* 2 bytes offset from GPIO base */ +#define HDR_TRANS_GPIO_VADDR 0x98/* 2 bytes offset from GPIO base */ +#define HDR_TRANS_GPIO_DADDR 0x9a/* 2 bytes offset from GPIO base */ +#define HDR_CLOCK_GPIO_BIT 0x9c/* 1 byte bit number */ +#define HDR_DATA_GPIO_BIT 0x9d/* 1 byte bit number */ +#define HDR_TRANS_GPIO_BIT 0x9e/* 1 byte bit number */ + +/* + * Command/Status area layout: Main part + */ + +/* Command/Status register: + * + * +---+ + * | STAT | RLEN | CLEN | CMD | + * | 8 | 8 | 8 | 8 | + *
[PATCH v3 2/5] devres: Add devm_of_iomap()
There are still quite a few cases where a device might want
to get to a different node of the device-tree, obtain the
resources and map them.
We have of_iomap() and of_io_request_and_map() but they both
have shortcomings, such as not returning the size of the
resource found (which can be useful) and not being "managed".
This adds a devm_of_iomap() that provides all of these and
should probably replace uses of the above in most drivers.
Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Linus Walleij
Reviewed-by: Joel Stanley
---
include/linux/device.h | 4
lib/devres.c | 36
2 files changed, 40 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 477956990f5e..96249d790374 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -688,6 +688,10 @@ extern void devm_free_pages(struct device *dev, unsigned
long addr);
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+void __iomem *devm_of_iomap(struct device *dev,
+ struct device_node *node, int index,
+ resource_size_t *size);
+
/* allows to add/remove a custom action to devres stack */
int devm_add_action(struct device *dev, void (*action)(void *), void *data);
void devm_remove_action(struct device *dev, void (*action)(void *), void
*data);
diff --git a/lib/devres.c b/lib/devres.c
index 5bec1120b392..faccf1a037d0 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
enum devm_ioremap_type {
DEVM_IOREMAP = 0,
@@ -162,6 +163,41 @@ void __iomem *devm_ioremap_resource(struct device *dev,
struct resource *res)
}
EXPORT_SYMBOL(devm_ioremap_resource);
+/*
+ * devm_of_iomap - Requests a resource and maps the memory mapped IO
+ *for a given device_node managed by a given device
+ *
+ * Checks that a resource is a valid memory region, requests the memory
+ * region and ioremaps it. All operations are managed and will be undone
+ * on driver detach of the device.
+ *
+ * This is to be used when a device requests/maps resources described
+ * by other device tree nodes (children or otherwise).
+ *
+ * @dev: The device "managing" the resource
+ * @node: The device-tree node where the resource resides
+ * @index: index of the MMIO range in the "reg" property
+ * @size: Returns the size of the resource (pass NULL if not needed)
+ * Returns a pointer to the requested and mapped memory or an ERR_PTR() encoded
+ * error code on failure. Usage example:
+ *
+ * base = devm_of_iomap(>dev, node, 0, NULL);
+ * if (IS_ERR(base))
+ * return PTR_ERR(base);
+ */
+void __iomem *devm_of_iomap(struct device *dev, struct device_node *node, int
index,
+ resource_size_t *size)
+{
+ struct resource res;
+
+ if (of_address_to_resource(node, index, ))
+ return IOMEM_ERR_PTR(-EINVAL);
+ if (size)
+ *size = resource_size();
+ return devm_ioremap_resource(dev, );
+}
+EXPORT_SYMBOL(devm_of_iomap);
+
#ifdef CONFIG_HAS_IOPORT_MAP
/*
* Generic iomap devres
--
2.17.1
[PATCH v3 4/5] arm: dts: OpenPower Romulus system can use coprocessor for FSI
Signed-off-by: Benjamin Herrenschmidt
---
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
index 347938673c83..4f4e42e47e3f 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
@@ -37,6 +37,11 @@
compatible = "shared-dma-pool";
reusable;
};
+
+ coldfire_memory: codefire_memory@9ef0 {
+ reg = <0x9ef0 0x0010>;
+ no-map;
+ };
};
leds {
@@ -56,10 +61,13 @@
};
fsi: gpio-fsi {
- compatible = "fsi-master-gpio", "fsi-master";
+ compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
#address-cells = <2>;
#size-cells = <0>;
- no-gpio-delays;
+
+ memory-region = <_memory>;
+ aspeed,sram = <>;
+ aspeed,cvic = <>;
clock-gpios = < ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
data-gpios = < ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
--
2.17.1
[PATCH v3 4/5] arm: dts: OpenPower Romulus system can use coprocessor for FSI
Signed-off-by: Benjamin Herrenschmidt
---
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
index 347938673c83..4f4e42e47e3f 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
@@ -37,6 +37,11 @@
compatible = "shared-dma-pool";
reusable;
};
+
+ coldfire_memory: codefire_memory@9ef0 {
+ reg = <0x9ef0 0x0010>;
+ no-map;
+ };
};
leds {
@@ -56,10 +61,13 @@
};
fsi: gpio-fsi {
- compatible = "fsi-master-gpio", "fsi-master";
+ compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
#address-cells = <2>;
#size-cells = <0>;
- no-gpio-delays;
+
+ memory-region = <_memory>;
+ aspeed,sram = <>;
+ aspeed,cvic = <>;
clock-gpios = < ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
data-gpios = < ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
--
2.17.1
[PATCH v3 2/5] devres: Add devm_of_iomap()
There are still quite a few cases where a device might want
to get to a different node of the device-tree, obtain the
resources and map them.
We have of_iomap() and of_io_request_and_map() but they both
have shortcomings, such as not returning the size of the
resource found (which can be useful) and not being "managed".
This adds a devm_of_iomap() that provides all of these and
should probably replace uses of the above in most drivers.
Signed-off-by: Benjamin Herrenschmidt
Reviewed-by: Linus Walleij
Reviewed-by: Joel Stanley
---
include/linux/device.h | 4
lib/devres.c | 36
2 files changed, 40 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 477956990f5e..96249d790374 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -688,6 +688,10 @@ extern void devm_free_pages(struct device *dev, unsigned
long addr);
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+void __iomem *devm_of_iomap(struct device *dev,
+ struct device_node *node, int index,
+ resource_size_t *size);
+
/* allows to add/remove a custom action to devres stack */
int devm_add_action(struct device *dev, void (*action)(void *), void *data);
void devm_remove_action(struct device *dev, void (*action)(void *), void
*data);
diff --git a/lib/devres.c b/lib/devres.c
index 5bec1120b392..faccf1a037d0 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
enum devm_ioremap_type {
DEVM_IOREMAP = 0,
@@ -162,6 +163,41 @@ void __iomem *devm_ioremap_resource(struct device *dev,
struct resource *res)
}
EXPORT_SYMBOL(devm_ioremap_resource);
+/*
+ * devm_of_iomap - Requests a resource and maps the memory mapped IO
+ *for a given device_node managed by a given device
+ *
+ * Checks that a resource is a valid memory region, requests the memory
+ * region and ioremaps it. All operations are managed and will be undone
+ * on driver detach of the device.
+ *
+ * This is to be used when a device requests/maps resources described
+ * by other device tree nodes (children or otherwise).
+ *
+ * @dev: The device "managing" the resource
+ * @node: The device-tree node where the resource resides
+ * @index: index of the MMIO range in the "reg" property
+ * @size: Returns the size of the resource (pass NULL if not needed)
+ * Returns a pointer to the requested and mapped memory or an ERR_PTR() encoded
+ * error code on failure. Usage example:
+ *
+ * base = devm_of_iomap(>dev, node, 0, NULL);
+ * if (IS_ERR(base))
+ * return PTR_ERR(base);
+ */
+void __iomem *devm_of_iomap(struct device *dev, struct device_node *node, int
index,
+ resource_size_t *size)
+{
+ struct resource res;
+
+ if (of_address_to_resource(node, index, ))
+ return IOMEM_ERR_PTR(-EINVAL);
+ if (size)
+ *size = resource_size();
+ return devm_ioremap_resource(dev, );
+}
+EXPORT_SYMBOL(devm_of_iomap);
+
#ifdef CONFIG_HAS_IOPORT_MAP
/*
* Generic iomap devres
--
2.17.1
[PATCH v3 5/5] arm: dts: OpenPower Palmetto system can use coprocessor for FSI
This switches away from userspace bitbanging to kernel FSI
using the coprocessor.
Signed-off-by: Benjamin Herrenschmidt
---
arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 28 ++-
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
index e6095f51ecf5..feec377c04d4 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
@@ -31,6 +31,11 @@
no-map;
reg = <0x9800 0x0100>; /* 16MB */
};
+
+ coldfire_memory: codefire_memory@5ee0 {
+ reg = <0x5ee0 0x0020>;
+ no-map;
+ };
};
leds {
@@ -49,6 +54,22 @@
};
};
+ fsi: gpio-fsi {
+ compatible = "aspeed,ast2400-cf-fsi-master", "fsi-master";
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ memory-region = <_memory>;
+ aspeed,sram = <>;
+ aspeed,cvic = <>;
+
+ clock-gpios = < ASPEED_GPIO(A, 4) GPIO_ACTIVE_HIGH>;
+ data-gpios = < ASPEED_GPIO(A, 5) GPIO_ACTIVE_HIGH>;
+ mux-gpios = < ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
+ enable-gpios = < ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
+ trans-gpios = < ASPEED_GPIO(H, 6) GPIO_ACTIVE_HIGH>;
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -323,13 +344,6 @@
line-name = "SYS_PWROK_BMC";
};
- pin_gpio_h6 {
- gpio-hog;
- gpios = ;
- output-high;
- line-name = "SCM1_FSI0_DATA_EN";
- };
-
pin_gpio_h7 {
gpio-hog;
gpios = ;
--
2.17.1
[PATCH v3 5/5] arm: dts: OpenPower Palmetto system can use coprocessor for FSI
This switches away from userspace bitbanging to kernel FSI
using the coprocessor.
Signed-off-by: Benjamin Herrenschmidt
---
arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 28 ++-
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
index e6095f51ecf5..feec377c04d4 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
@@ -31,6 +31,11 @@
no-map;
reg = <0x9800 0x0100>; /* 16MB */
};
+
+ coldfire_memory: codefire_memory@5ee0 {
+ reg = <0x5ee0 0x0020>;
+ no-map;
+ };
};
leds {
@@ -49,6 +54,22 @@
};
};
+ fsi: gpio-fsi {
+ compatible = "aspeed,ast2400-cf-fsi-master", "fsi-master";
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ memory-region = <_memory>;
+ aspeed,sram = <>;
+ aspeed,cvic = <>;
+
+ clock-gpios = < ASPEED_GPIO(A, 4) GPIO_ACTIVE_HIGH>;
+ data-gpios = < ASPEED_GPIO(A, 5) GPIO_ACTIVE_HIGH>;
+ mux-gpios = < ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
+ enable-gpios = < ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
+ trans-gpios = < ASPEED_GPIO(H, 6) GPIO_ACTIVE_HIGH>;
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -323,13 +344,6 @@
line-name = "SYS_PWROK_BMC";
};
- pin_gpio_h6 {
- gpio-hog;
- gpios = ;
- output-high;
- line-name = "SCM1_FSI0_DATA_EN";
- };
-
pin_gpio_h7 {
gpio-hog;
gpios = ;
--
2.17.1
Re: [PATCH] ring_buffer: Update logging to use single line output
On Wed, 2018-07-11 at 22:57 -0400, Steven Rostedt wrote:
> On Fri, 11 May 2018 14:39:18 -0700
> Joe Perches wrote:
>
> > With a possible change to pr_fmt coming, the logging output can
> > become unbalanced when an initial line has a prefix and subsequent
> > lines do not when a multiple line pr_ is emitted.
> >
> > Fix it by emitting a single line.
> >
> > Miscellanea:
> >
> > o Convert consecutive tests of total_lost and !total_lost to if/else
>
> I just noticed this patch. Please don't send patches Cc'd to other
> threads. They need to start a new thread, otherwise, like this one, it
> will most likely be lost.
>
> If you want this applied still, please resend it properly.
An email sent directly to you should not be lost by you.
> -- Steve
>
> >
> > Signed-off-by: Joe Perches
> > ---
> > kernel/trace/ring_buffer.c | 7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> > index c9cb9767d49b..ee74494a2da3 100644
> > --- a/kernel/trace/ring_buffer.c
> > +++ b/kernel/trace/ring_buffer.c
> > @@ -5132,10 +5132,9 @@ static __init int test_ringbuffer(void)
> > pr_info("total events: %ld\n", total_lost +
> > total_read);
> > pr_info(" recorded len bytes: %ld\n", total_len);
> > pr_info(" recorded size bytes: %ld\n", total_size);
> > - if (total_lost)
> > - pr_info(" With dropped events, record len and size may
> > not match\n"
> > - " alloced and written from above\n");
> > - if (!total_lost) {
> > + if (total_lost) {
> > + pr_info(" With dropped events, record len and size may
> > not match alloced and written from above\n");
> > + } else {
> > if (RB_WARN_ON(buffer, total_len != total_alloc ||
> >total_size != total_written))
> > break;
>
>
Re: [PATCH] ring_buffer: Update logging to use single line output
On Wed, 2018-07-11 at 22:57 -0400, Steven Rostedt wrote:
> On Fri, 11 May 2018 14:39:18 -0700
> Joe Perches wrote:
>
> > With a possible change to pr_fmt coming, the logging output can
> > become unbalanced when an initial line has a prefix and subsequent
> > lines do not when a multiple line pr_ is emitted.
> >
> > Fix it by emitting a single line.
> >
> > Miscellanea:
> >
> > o Convert consecutive tests of total_lost and !total_lost to if/else
>
> I just noticed this patch. Please don't send patches Cc'd to other
> threads. They need to start a new thread, otherwise, like this one, it
> will most likely be lost.
>
> If you want this applied still, please resend it properly.
An email sent directly to you should not be lost by you.
> -- Steve
>
> >
> > Signed-off-by: Joe Perches
> > ---
> > kernel/trace/ring_buffer.c | 7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> > index c9cb9767d49b..ee74494a2da3 100644
> > --- a/kernel/trace/ring_buffer.c
> > +++ b/kernel/trace/ring_buffer.c
> > @@ -5132,10 +5132,9 @@ static __init int test_ringbuffer(void)
> > pr_info("total events: %ld\n", total_lost +
> > total_read);
> > pr_info(" recorded len bytes: %ld\n", total_len);
> > pr_info(" recorded size bytes: %ld\n", total_size);
> > - if (total_lost)
> > - pr_info(" With dropped events, record len and size may
> > not match\n"
> > - " alloced and written from above\n");
> > - if (!total_lost) {
> > + if (total_lost) {
> > + pr_info(" With dropped events, record len and size may
> > not match alloced and written from above\n");
> > + } else {
> > if (RB_WARN_ON(buffer, total_len != total_alloc ||
> >total_size != total_written))
> > break;
>
>
Re: linux-next: duplicate patches in the gfs2 and xfs trees
Hi Andreas,
On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher
wrote:
>
> this is what I'm seeing (git log --pretty=oneline --abbrev-commit
> --graph ^origin/master gfs2/for-next):
>
> * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize
> == PAGE_SIZE
> * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads
> * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next
> |\
> | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support
> to iomap_readpage_actor
> | * ec181f6782d8 iomap: support direct I/O to inline data
> | * 09230435dffd iomap: refactor iomap_dio_actor
> | * c03cea42149d iomap: add initial support for writes without buffer heads
> | * 72b4daa24129 iomap: add an iomap-based readpage and readpages
> implementation
> * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap
> * | 2e2834ef1797 GFS2: Fix recovery issues for spectators
> * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next
> |\ \
> | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end}
> | * | 967bcc91b044 gfs2: iomap direct I/O support
> | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup
> | * | 64bc06bb32ee gfs2: iomap buffered write support
> | * | d505a96a3b16 gfs2: Further iomap cleanups
> | |/
> | * e184fde6f3f5 iomap: add private pointer to struct iomap
> | * 63899c6f8851 iomap: add a page_done callback
> | * 19e0c58f6552 iomap: generic inline data handling
> | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously
> | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new
> | * a6d639da63ae fs: factor out a __generic_write_end helper
> * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t
> * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of posix_acl_to_xattr
> * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have
> blocks reserved
> * d1475c07f7ce GFS2: rgrp free blocks used incorrectly
> * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd
> * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code
> * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly
> * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole
> * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock
> * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes
>
> Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on
> xfs/iomap-4.19-merge. That was my initial merge from
> xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge
> commit. I've then merged our iomap-write branch into for-next, with
> two additional commits on top. Then comes the rest of
> xfs/iomap-4.19-merge (that branch has moved ahead in the meantime),
> again with two more commits on top.
>
> There are no rebased commits, you're looking at the exact same commits.
The problem is that commits
a6d639da63ae fs: factor out a __generic_write_end helper
to
806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support
have been rebased in the xfs tree from a base of v4.18-rc1 to
v4.18-rc4, so that those patches now appear twice in linux-next where I
have merged the gfs2 tree and the xfs tree. This has caused a few
conflicts today as there are more changes to the same files affected by
those commits in the xfs tree. to iomap_readpage_actor
What should have happened is that those commits should not have been
rebased, so either the xfs tree needs rebuilding to use the old
commits, or your tree needs to be rebuilt using the new commits from
the xfs tree. This is why we do not like the rebasing of published
trees (especially when a subset of the tree is shared with other
developers).
Also, if you are going to merge (part of) another tree you need to make
sure that the other maintainer will not do a rebase of it (I assume
that this was probably talked about).
--
Cheers,
Stephen Rothwell
pgpxh8dvdhgbh.pgp
Description: OpenPGP digital signature
Re: linux-next: duplicate patches in the gfs2 and xfs trees
Hi Andreas,
On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher
wrote:
>
> this is what I'm seeing (git log --pretty=oneline --abbrev-commit
> --graph ^origin/master gfs2/for-next):
>
> * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize
> == PAGE_SIZE
> * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads
> * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next
> |\
> | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support
> to iomap_readpage_actor
> | * ec181f6782d8 iomap: support direct I/O to inline data
> | * 09230435dffd iomap: refactor iomap_dio_actor
> | * c03cea42149d iomap: add initial support for writes without buffer heads
> | * 72b4daa24129 iomap: add an iomap-based readpage and readpages
> implementation
> * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap
> * | 2e2834ef1797 GFS2: Fix recovery issues for spectators
> * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next
> |\ \
> | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end}
> | * | 967bcc91b044 gfs2: iomap direct I/O support
> | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup
> | * | 64bc06bb32ee gfs2: iomap buffered write support
> | * | d505a96a3b16 gfs2: Further iomap cleanups
> | |/
> | * e184fde6f3f5 iomap: add private pointer to struct iomap
> | * 63899c6f8851 iomap: add a page_done callback
> | * 19e0c58f6552 iomap: generic inline data handling
> | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously
> | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new
> | * a6d639da63ae fs: factor out a __generic_write_end helper
> * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t
> * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of posix_acl_to_xattr
> * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have
> blocks reserved
> * d1475c07f7ce GFS2: rgrp free blocks used incorrectly
> * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd
> * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code
> * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly
> * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole
> * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock
> * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes
>
> Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on
> xfs/iomap-4.19-merge. That was my initial merge from
> xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge
> commit. I've then merged our iomap-write branch into for-next, with
> two additional commits on top. Then comes the rest of
> xfs/iomap-4.19-merge (that branch has moved ahead in the meantime),
> again with two more commits on top.
>
> There are no rebased commits, you're looking at the exact same commits.
The problem is that commits
a6d639da63ae fs: factor out a __generic_write_end helper
to
806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support
have been rebased in the xfs tree from a base of v4.18-rc1 to
v4.18-rc4, so that those patches now appear twice in linux-next where I
have merged the gfs2 tree and the xfs tree. This has caused a few
conflicts today as there are more changes to the same files affected by
those commits in the xfs tree. to iomap_readpage_actor
What should have happened is that those commits should not have been
rebased, so either the xfs tree needs rebuilding to use the old
commits, or your tree needs to be rebuilt using the new commits from
the xfs tree. This is why we do not like the rebasing of published
trees (especially when a subset of the tree is shared with other
developers).
Also, if you are going to merge (part of) another tree you need to make
sure that the other maintainer will not do a rebase of it (I assume
that this was probably talked about).
--
Cheers,
Stephen Rothwell
pgpxh8dvdhgbh.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 2/7] thermal: tsens: Add support to split up register address space into two
On Thu, Jul 12, 2018 at 12:07 AM, Doug Anderson wrote:
> Hi,
>
> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria
> wrote:
>> There are two banks of registers for v2 TSENS IPs: SROT and TM. On older
>> SoCs these were contiguous, leading to DTs mapping them as one register
>> address space of size 0x2000. In newer SoCs, these two banks are not
>> contiguous anymore.
>>
>> Fixing old DTs to split the address space into allows us to have cleaner
>> common code e.g. get_temp() that is shared across new and old platforms.
>
> This makes it sound like old DTs won't be supported anymore. ...but
> the code says otherwise. I'd just remove the above paragraph.
OK.
>
>> @@ -126,11 +127,21 @@ static const struct regmap_config tsens_config = {
>> int __init init_common(struct tsens_device *tmdev)
>> {
>> void __iomem *base;
>> + struct platform_device *op =
>> of_find_device_by_node(tmdev->dev->of_node);
>>
>> + if (!op)
>> + return -EINVAL;
>> base = of_iomap(tmdev->dev->of_node, 0);
>> if (!base)
>> return -EINVAL;
>>
>> + if (op->num_resources > 1) {
>
> Maybe add a comment here that says that we don't actually map the SROT
> yet because you don't read anything from there? I kept getting
> confused about how this patch could possibly work with no code to map
> SROT...
OK. The SROT comment got separated (patch 3) during patch refactoring.
Will add a comment.
>> + tmdev->tm_offset = 0;
>> + } else {
>> + /* old DTs where SROT and TM were in a contiguous 2K block */
>> + tmdev->tm_offset = 0x1000;
>
> This patch without patch #4 will break compatibility. You should
> squash part of patch #4 into this one, specifically:
>
> -#define STATUS_OFFSET 0x10a0
> -#define LAST_TEMP_MASK 0xfff
> +#define STATUS_OFFSET 0xa0
> +#define LAST_TEMP_MASK 0xfff
>
> Without that you break bisect-ability and also confuse anyone trying
> to look at this patch.
Thanks. Will fix.
Re: [PATCH v6 2/7] thermal: tsens: Add support to split up register address space into two
On Thu, Jul 12, 2018 at 12:07 AM, Doug Anderson wrote:
> Hi,
>
> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria
> wrote:
>> There are two banks of registers for v2 TSENS IPs: SROT and TM. On older
>> SoCs these were contiguous, leading to DTs mapping them as one register
>> address space of size 0x2000. In newer SoCs, these two banks are not
>> contiguous anymore.
>>
>> Fixing old DTs to split the address space into allows us to have cleaner
>> common code e.g. get_temp() that is shared across new and old platforms.
>
> This makes it sound like old DTs won't be supported anymore. ...but
> the code says otherwise. I'd just remove the above paragraph.
OK.
>
>> @@ -126,11 +127,21 @@ static const struct regmap_config tsens_config = {
>> int __init init_common(struct tsens_device *tmdev)
>> {
>> void __iomem *base;
>> + struct platform_device *op =
>> of_find_device_by_node(tmdev->dev->of_node);
>>
>> + if (!op)
>> + return -EINVAL;
>> base = of_iomap(tmdev->dev->of_node, 0);
>> if (!base)
>> return -EINVAL;
>>
>> + if (op->num_resources > 1) {
>
> Maybe add a comment here that says that we don't actually map the SROT
> yet because you don't read anything from there? I kept getting
> confused about how this patch could possibly work with no code to map
> SROT...
OK. The SROT comment got separated (patch 3) during patch refactoring.
Will add a comment.
>> + tmdev->tm_offset = 0;
>> + } else {
>> + /* old DTs where SROT and TM were in a contiguous 2K block */
>> + tmdev->tm_offset = 0x1000;
>
> This patch without patch #4 will break compatibility. You should
> squash part of patch #4 into this one, specifically:
>
> -#define STATUS_OFFSET 0x10a0
> -#define LAST_TEMP_MASK 0xfff
> +#define STATUS_OFFSET 0xa0
> +#define LAST_TEMP_MASK 0xfff
>
> Without that you break bisect-ability and also confuse anyone trying
> to look at this patch.
Thanks. Will fix.
Re: linux-next: build warning after merge of the scsi-mkp tree
Hi all,
On Wed, 11 Jul 2018 14:17:37 +1000 Stephen Rothwell
wrote:
>
> After merging the scsi-mkp tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> In file included from include/linux/spinlock_types.h:18:0,
> from include/linux/spinlock.h:82,
> from drivers/scsi/libfc/fc_rport.c:61:
> drivers/scsi/libfc/fc_rport.c: In function 'fc_rport_recv_req':
> include/linux/lockdep.h:347:45: warning: 'rdata' may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> #define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map)
> ^
> drivers/scsi/libfc/fc_rport.c:1832:24: note: 'rdata' was declared here
> struct fc_rport_priv *rdata;
> ^
>
> Introduced by commit
>
> ee35624e1e4e ("scsi: libfc: Add lockdep annotations")
>
> It is actually complaining about function fc_rport_recv_plogi_req()
> (presumably it is being inlined) and this looks like an actual bug :-(
This warning now appears after the merge of the scsi tree.
--
Cheers,
Stephen Rothwell
pgptnJcDfqT_d.pgp
Description: OpenPGP digital signature
Re: linux-next: build warning after merge of the scsi-mkp tree
Hi all,
On Wed, 11 Jul 2018 14:17:37 +1000 Stephen Rothwell
wrote:
>
> After merging the scsi-mkp tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> In file included from include/linux/spinlock_types.h:18:0,
> from include/linux/spinlock.h:82,
> from drivers/scsi/libfc/fc_rport.c:61:
> drivers/scsi/libfc/fc_rport.c: In function 'fc_rport_recv_req':
> include/linux/lockdep.h:347:45: warning: 'rdata' may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> #define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map)
> ^
> drivers/scsi/libfc/fc_rport.c:1832:24: note: 'rdata' was declared here
> struct fc_rport_priv *rdata;
> ^
>
> Introduced by commit
>
> ee35624e1e4e ("scsi: libfc: Add lockdep annotations")
>
> It is actually complaining about function fc_rport_recv_plogi_req()
> (presumably it is being inlined) and this looks like an actual bug :-(
This warning now appears after the merge of the scsi tree.
--
Cheers,
Stephen Rothwell
pgptnJcDfqT_d.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the scsi-mkp tree with Linus' tree
Hi all,
On Wed, 11 Jul 2018 14:04:57 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
> MAINTAINERS
>
> between commit:
>
> 54e45716a84a ("scsi: remove NCR_D700 driver")
>
> from Linus' tree and commit:
>
> 01a21986f8ed ("MAINTAINERS: Add Sam as the maintainer for NCSI")
>
> from the scsi-mkp tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc MAINTAINERS
> index e5f8823b5f02,f3de5d37179a..
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@@ -9810,17 -9750,6 +9810,11 @@@ F: drivers/scsi/mac_scsi.
> F: drivers/scsi/sun3_scsi.*
> F: drivers/scsi/sun3_scsi_vme.c
>
> - NCR DUAL 700 SCSI DRIVER (MICROCHANNEL)
> - M: "James E.J. Bottomley"
> - L: linux-s...@vger.kernel.org
> - S: Maintained
> - F: drivers/scsi/NCR_D700.*
> -
> +NCSI LIBRARY:
> +M: Samuel Mendoza-Jonas
> +S: Maintained
> +F: net/ncsi/
> +
> NCT6775 HARDWARE MONITOR DRIVER
> M: Guenter Roeck
> L: linux-hw...@vger.kernel.org
This conflict is now between the scsi tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpTDUtJs8UMs.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the scsi-mkp tree with Linus' tree
Hi all,
On Wed, 11 Jul 2018 14:04:57 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
> MAINTAINERS
>
> between commit:
>
> 54e45716a84a ("scsi: remove NCR_D700 driver")
>
> from Linus' tree and commit:
>
> 01a21986f8ed ("MAINTAINERS: Add Sam as the maintainer for NCSI")
>
> from the scsi-mkp tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc MAINTAINERS
> index e5f8823b5f02,f3de5d37179a..
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@@ -9810,17 -9750,6 +9810,11 @@@ F: drivers/scsi/mac_scsi.
> F: drivers/scsi/sun3_scsi.*
> F: drivers/scsi/sun3_scsi_vme.c
>
> - NCR DUAL 700 SCSI DRIVER (MICROCHANNEL)
> - M: "James E.J. Bottomley"
> - L: linux-s...@vger.kernel.org
> - S: Maintained
> - F: drivers/scsi/NCR_D700.*
> -
> +NCSI LIBRARY:
> +M: Samuel Mendoza-Jonas
> +S: Maintained
> +F: net/ncsi/
> +
> NCT6775 HARDWARE MONITOR DRIVER
> M: Guenter Roeck
> L: linux-hw...@vger.kernel.org
This conflict is now between the scsi tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpTDUtJs8UMs.pgp
Description: OpenPGP digital signature
Re: [PATCH v9 4/7] tracepoint: Make rcuidle tracepoint callers use SRCU
On Wed, Jul 11, 2018 at 11:21:20PM -0400, Steven Rostedt wrote:
> On Wed, 11 Jul 2018 13:52:49 -0700
> Joel Fernandes wrote:
>
> > > #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
> > > extern struct tracepoint __tracepoint_##name; \
> > > static inline void trace_##name(proto) \
> > > { \
> > > if (static_key_false(&__tracepoint_##name.key)) \
> > > __DO_TRACE(&__tracepoint_##name,\
> > > TP_PROTO(data_proto), \
> > > TP_ARGS(data_args), \
> > > TP_CONDITION(cond), 0); \
> > > if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { \
> > > rcu_read_lock_sched_notrace(); \
> > > rcu_dereference_sched(__tracepoint_##name.funcs);\
> > > rcu_read_unlock_sched_notrace();\
> > > } \
> > > }
> > >
> > > Because lockdep would only trigger warnings when the tracepoint was
> > > enabled and used in a place it shouldn't be, we added the above
> > > IS_ENABLED(CONFIG_LOCKDEP) part to test regardless if the the
> > > tracepoint was enabled or not. Because we do this, we don't need to
> > > have the test in the __DO_TRACE() code itself. That means we can clean
> > > up the code as per Peter's suggestion.
> >
> > Sounds good, I'm Ok with making this change.
> >
> > Just to clarify, are you proposing to change the rcu_dereference_sched to
> > rcu_dereference_raw in both __DECLARE_TRACE and __DO_TRACE?
>
> No, just in __DO_TRACE(). The rcu_dereference_sched() above in
> __DECLARE_TRACE() in the if (IS_ENABLED(CONFIG_LOCKDEP) block is
> required to show the warnings if trace_##name() is used wrong, and is
> the reason we can use rcu_dereference_raw() in __DO_TRACE() in the
> first place ;-)
>
> This brings up another point. We should probably add to
> __DECLARE_TRACE_RCU() this:
>
> #ifndef MODULE
> #define __DECLARE_TRACE_RCU(name, proto, args, cond, data_proto, data_args) \
> static inline void trace_##name##_rcuidle(proto)\
> { \
> if (static_key_false(&__tracepoint_##name.key)) \
> __DO_TRACE(&__tracepoint_##name,\
> TP_PROTO(data_proto), \
> TP_ARGS(data_args), \
> TP_CONDITION(cond), 1); \
> + if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { \
> + int idx;\
> + idx = srcu_read_lock_notrace(_srcu); \
> + srcu_dereference_notrace(__tracepoint_##name.funcs, \
> + _srcu); \
> + srcu_read_unlock_notrace(_srcu, idx); \
> + } \
> }
> #else
>
>
> So that lockdep works with trace_##name##__rcuidle() when the trace
> event is not enabled.
>
> But that should be a separate patch and not part of this series. I may
> write that up tomorrow.
Yes, that sounds good to me and would be good to add the safe guard there.
But you meant srcu_dereference above, not srcu_dereference_notrace right?
Meanwhile I'll drop that lockdep_recursion tomorrow and run some tests and
see how it behaves with Peter's changes.
thanks!
- Joel
Re: [PATCH v9 4/7] tracepoint: Make rcuidle tracepoint callers use SRCU
On Wed, Jul 11, 2018 at 11:21:20PM -0400, Steven Rostedt wrote:
> On Wed, 11 Jul 2018 13:52:49 -0700
> Joel Fernandes wrote:
>
> > > #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
> > > extern struct tracepoint __tracepoint_##name; \
> > > static inline void trace_##name(proto) \
> > > { \
> > > if (static_key_false(&__tracepoint_##name.key)) \
> > > __DO_TRACE(&__tracepoint_##name,\
> > > TP_PROTO(data_proto), \
> > > TP_ARGS(data_args), \
> > > TP_CONDITION(cond), 0); \
> > > if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { \
> > > rcu_read_lock_sched_notrace(); \
> > > rcu_dereference_sched(__tracepoint_##name.funcs);\
> > > rcu_read_unlock_sched_notrace();\
> > > } \
> > > }
> > >
> > > Because lockdep would only trigger warnings when the tracepoint was
> > > enabled and used in a place it shouldn't be, we added the above
> > > IS_ENABLED(CONFIG_LOCKDEP) part to test regardless if the the
> > > tracepoint was enabled or not. Because we do this, we don't need to
> > > have the test in the __DO_TRACE() code itself. That means we can clean
> > > up the code as per Peter's suggestion.
> >
> > Sounds good, I'm Ok with making this change.
> >
> > Just to clarify, are you proposing to change the rcu_dereference_sched to
> > rcu_dereference_raw in both __DECLARE_TRACE and __DO_TRACE?
>
> No, just in __DO_TRACE(). The rcu_dereference_sched() above in
> __DECLARE_TRACE() in the if (IS_ENABLED(CONFIG_LOCKDEP) block is
> required to show the warnings if trace_##name() is used wrong, and is
> the reason we can use rcu_dereference_raw() in __DO_TRACE() in the
> first place ;-)
>
> This brings up another point. We should probably add to
> __DECLARE_TRACE_RCU() this:
>
> #ifndef MODULE
> #define __DECLARE_TRACE_RCU(name, proto, args, cond, data_proto, data_args) \
> static inline void trace_##name##_rcuidle(proto)\
> { \
> if (static_key_false(&__tracepoint_##name.key)) \
> __DO_TRACE(&__tracepoint_##name,\
> TP_PROTO(data_proto), \
> TP_ARGS(data_args), \
> TP_CONDITION(cond), 1); \
> + if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { \
> + int idx;\
> + idx = srcu_read_lock_notrace(_srcu); \
> + srcu_dereference_notrace(__tracepoint_##name.funcs, \
> + _srcu); \
> + srcu_read_unlock_notrace(_srcu, idx); \
> + } \
> }
> #else
>
>
> So that lockdep works with trace_##name##__rcuidle() when the trace
> event is not enabled.
>
> But that should be a separate patch and not part of this series. I may
> write that up tomorrow.
Yes, that sounds good to me and would be good to add the safe guard there.
But you meant srcu_dereference above, not srcu_dereference_notrace right?
Meanwhile I'll drop that lockdep_recursion tomorrow and run some tests and
see how it behaves with Peter's changes.
thanks!
- Joel
Re: [PATCH] console: Replace #if 1 with a bool to ignore WARN_CONSOLE_UNLOCKED()
On (07/11/18 23:09), Steven Rostedt wrote: > > On (07/11/18 15:17), Steven Rostedt wrote: > > > +bool ignore_console_lock_warning __read_mostly; > > > +EXPORT_SYMBOL(ignore_console_lock_warning); > > > > OK. So, to recap, > > We made is_console_locked() EXPORT_SYMBOL recently [it's still in > > linux-next], > > so people could use WARN_CONSOLE_UNLOCKED in more places; this made other > > people unhappy, so now we add another EXPORT_SYMBOL to the picture, which > > will > > disable those newly added WARN_CONSOLE_UNLOCKED and make other people happy > > again. > > Note, it only made people that added a module parameter that disables > grabbing the console lock in the first place for debugging purposes > only. The added WARN_CONSOLE_UNLOCKED() are good. Nobody complaining > that they exist. They are complaining that it breaks one of their > debugging work flows, and need to disable it when they are doing so. True, but at the same time nobody complained that we didn't have those extra WARN_CONSOLE_UNLOCKED()-s. Just saying. Over all I agree that there is probably some value in those extra WARN-s. > I could add a comment explaining why it exists. Something like: > > /* > * Set this is you need to quiet WARN_CONSOLE_UNLOCKED() for debugging > * purposes. > */ s/is you/if you/ Suggested-by: one-of-those-commit...@youknowwhoyouare.org ;) -ss
Re: [PATCH] console: Replace #if 1 with a bool to ignore WARN_CONSOLE_UNLOCKED()
On (07/11/18 23:09), Steven Rostedt wrote: > > On (07/11/18 15:17), Steven Rostedt wrote: > > > +bool ignore_console_lock_warning __read_mostly; > > > +EXPORT_SYMBOL(ignore_console_lock_warning); > > > > OK. So, to recap, > > We made is_console_locked() EXPORT_SYMBOL recently [it's still in > > linux-next], > > so people could use WARN_CONSOLE_UNLOCKED in more places; this made other > > people unhappy, so now we add another EXPORT_SYMBOL to the picture, which > > will > > disable those newly added WARN_CONSOLE_UNLOCKED and make other people happy > > again. > > Note, it only made people that added a module parameter that disables > grabbing the console lock in the first place for debugging purposes > only. The added WARN_CONSOLE_UNLOCKED() are good. Nobody complaining > that they exist. They are complaining that it breaks one of their > debugging work flows, and need to disable it when they are doing so. True, but at the same time nobody complained that we didn't have those extra WARN_CONSOLE_UNLOCKED()-s. Just saying. Over all I agree that there is probably some value in those extra WARN-s. > I could add a comment explaining why it exists. Something like: > > /* > * Set this is you need to quiet WARN_CONSOLE_UNLOCKED() for debugging > * purposes. > */ s/is you/if you/ Suggested-by: one-of-those-commit...@youknowwhoyouare.org ;) -ss
[PATCH v3 6/6] dt-bindings: xilinx: zynq: Add missing boards
The bindings were missing when the device-tree files were added Signed-off-by: Luis Araneda --- .../devicetree/bindings/arm/xilinx.txt | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt index d1a6deac90b5..26fe5ecc4332 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.txt +++ b/Documentation/devicetree/bindings/arm/xilinx.txt @@ -11,12 +11,29 @@ Additional compatible strings: - Adapteva Parallella board "adapteva,parallella" +- Avnet MicroZed board + "avnet,zynq-microzed" + "xlnx,zynq-microzed" + +- Avnet ZedBoard board + "avnet,zynq-zed" + "xlnx,zynq-zed" + +- Digilent Zybo board + "digilent,zynq-zybo" + - Digilent Zybo Z7 board "digilent,zynq-zybo-z7" - Xilinx CC108 internal board "xlnx,zynq-cc108" +- Xilinx ZC702 internal board + "xlnx,zynq-zc702" + +- Xilinx ZC706 internal board + "xlnx,zynq-zc706" + - Xilinx ZC770 internal board, with different FMC cards "xlnx,zynq-zc770-xm010" "xlnx,zynq-zc770-xm011" -- 2.18.0
[PATCH v3 5/6] dt-bindings: Move Paralella board to Xilinx
Move the Adapteva Parallela board to Xilinx dt-bindings, as it's based on a Zynq SoC from Xilinx Signed-off-by: Luis Araneda --- Documentation/devicetree/bindings/arm/adapteva.txt | 7 --- Documentation/devicetree/bindings/arm/xilinx.txt | 3 +++ 2 files changed, 3 insertions(+), 7 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/adapteva.txt diff --git a/Documentation/devicetree/bindings/arm/adapteva.txt b/Documentation/devicetree/bindings/arm/adapteva.txt deleted file mode 100644 index 1d8af9e36065.. --- a/Documentation/devicetree/bindings/arm/adapteva.txt +++ /dev/null @@ -1,7 +0,0 @@ -Adapteva Platforms Device Tree Bindings - -Parallella board - -Required root node properties: -- compatible = "adapteva,parallella"; diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt index a8e70a794d2e..d1a6deac90b5 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.txt +++ b/Documentation/devicetree/bindings/arm/xilinx.txt @@ -8,6 +8,9 @@ Required root node properties: Additional compatible strings: +- Adapteva Parallella board + "adapteva,parallella" + - Digilent Zybo Z7 board "digilent,zynq-zybo-z7" -- 2.18.0
[PATCH v3 6/6] dt-bindings: xilinx: zynq: Add missing boards
The bindings were missing when the device-tree files were added Signed-off-by: Luis Araneda --- .../devicetree/bindings/arm/xilinx.txt | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt index d1a6deac90b5..26fe5ecc4332 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.txt +++ b/Documentation/devicetree/bindings/arm/xilinx.txt @@ -11,12 +11,29 @@ Additional compatible strings: - Adapteva Parallella board "adapteva,parallella" +- Avnet MicroZed board + "avnet,zynq-microzed" + "xlnx,zynq-microzed" + +- Avnet ZedBoard board + "avnet,zynq-zed" + "xlnx,zynq-zed" + +- Digilent Zybo board + "digilent,zynq-zybo" + - Digilent Zybo Z7 board "digilent,zynq-zybo-z7" - Xilinx CC108 internal board "xlnx,zynq-cc108" +- Xilinx ZC702 internal board + "xlnx,zynq-zc702" + +- Xilinx ZC706 internal board + "xlnx,zynq-zc706" + - Xilinx ZC770 internal board, with different FMC cards "xlnx,zynq-zc770-xm010" "xlnx,zynq-zc770-xm011" -- 2.18.0
[PATCH v3 5/6] dt-bindings: Move Paralella board to Xilinx
Move the Adapteva Parallela board to Xilinx dt-bindings, as it's based on a Zynq SoC from Xilinx Signed-off-by: Luis Araneda --- Documentation/devicetree/bindings/arm/adapteva.txt | 7 --- Documentation/devicetree/bindings/arm/xilinx.txt | 3 +++ 2 files changed, 3 insertions(+), 7 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/adapteva.txt diff --git a/Documentation/devicetree/bindings/arm/adapteva.txt b/Documentation/devicetree/bindings/arm/adapteva.txt deleted file mode 100644 index 1d8af9e36065.. --- a/Documentation/devicetree/bindings/arm/adapteva.txt +++ /dev/null @@ -1,7 +0,0 @@ -Adapteva Platforms Device Tree Bindings - -Parallella board - -Required root node properties: -- compatible = "adapteva,parallella"; diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt index a8e70a794d2e..d1a6deac90b5 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.txt +++ b/Documentation/devicetree/bindings/arm/xilinx.txt @@ -8,6 +8,9 @@ Required root node properties: Additional compatible strings: +- Adapteva Parallella board + "adapteva,parallella" + - Digilent Zybo Z7 board "digilent,zynq-zybo-z7" -- 2.18.0
[PATCH v3 0/6] arm: dts: zynq: improvements and cleanup
This series attempts to standardize device naming and improve its information for better identification The values of the "compatible" and "model" device-tree properties are corrected for some devices, adding complementary information when necessary Changes since v2: - Split dt-bindings patch (too many changes) - Apply dts patches first (reorder) Changes since v1 (RFC): - Add values to compatible property instead of replacing them - Don't remove "internal" word from Xilinx boards on dt-bindings - Migrate content of adapteva dt-binding file into Xilinx's - Sort additional compatible strings alphabetically by manufacturer - Dropped patch that renamed the zedboard development board (no apparent benefit) - Dropped the patch that removed the "zynq" value from the compatible strings (breaks the ABI) Luis Araneda (6): arm: dts: zynq: Set correct manufacturer for ZedBoard and MicroZed boards arm: dts: zynq: correct and improve the model property of dt files dt-bindings: xilinx: zynq: Improve boards description dt-bindings: xilinx: zynq: Sort entries alphabetically dt-bindings: Move Paralella board to Xilinx dt-bindings: xilinx: zynq: Add missing boards .../devicetree/bindings/arm/adapteva.txt | 7 - .../devicetree/bindings/arm/xilinx.txt| 30 +++ arch/arm/boot/dts/zynq-cc108.dts | 2 +- arch/arm/boot/dts/zynq-microzed.dts | 4 +-- arch/arm/boot/dts/zynq-parallella.dts | 2 +- arch/arm/boot/dts/zynq-zc702.dts | 2 +- arch/arm/boot/dts/zynq-zc706.dts | 2 +- arch/arm/boot/dts/zynq-zc770-xm010.dts| 2 +- arch/arm/boot/dts/zynq-zc770-xm011.dts| 2 +- arch/arm/boot/dts/zynq-zc770-xm012.dts| 2 +- arch/arm/boot/dts/zynq-zc770-xm013.dts| 2 +- arch/arm/boot/dts/zynq-zed.dts| 4 +-- arch/arm/boot/dts/zynq-zybo-z7.dts| 2 +- arch/arm/boot/dts/zynq-zybo.dts | 2 +- 14 files changed, 39 insertions(+), 26 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/adapteva.txt -- 2.18.0
[PATCH v3 4/6] dt-bindings: xilinx: zynq: Sort entries alphabetically
Sort additional compatible strings (boards) alphabetically by their manufacturer and model number This will help when finding a board because they will be grouped by their manufacturer Signed-off-by: Luis Araneda --- Documentation/devicetree/bindings/arm/xilinx.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt index 4f1759b2bea7..a8e70a794d2e 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.txt +++ b/Documentation/devicetree/bindings/arm/xilinx.txt @@ -8,6 +8,9 @@ Required root node properties: Additional compatible strings: +- Digilent Zybo Z7 board + "digilent,zynq-zybo-z7" + - Xilinx CC108 internal board "xlnx,zynq-cc108" @@ -17,9 +20,6 @@ Additional compatible strings: "xlnx,zynq-zc770-xm012" "xlnx,zynq-zc770-xm013" -- Digilent Zybo Z7 board - "digilent,zynq-zybo-z7" - --- Xilinx Zynq UltraScale+ MPSoC Platforms Device Tree Bindings -- 2.18.0
[PATCH v3 0/6] arm: dts: zynq: improvements and cleanup
This series attempts to standardize device naming and improve its information for better identification The values of the "compatible" and "model" device-tree properties are corrected for some devices, adding complementary information when necessary Changes since v2: - Split dt-bindings patch (too many changes) - Apply dts patches first (reorder) Changes since v1 (RFC): - Add values to compatible property instead of replacing them - Don't remove "internal" word from Xilinx boards on dt-bindings - Migrate content of adapteva dt-binding file into Xilinx's - Sort additional compatible strings alphabetically by manufacturer - Dropped patch that renamed the zedboard development board (no apparent benefit) - Dropped the patch that removed the "zynq" value from the compatible strings (breaks the ABI) Luis Araneda (6): arm: dts: zynq: Set correct manufacturer for ZedBoard and MicroZed boards arm: dts: zynq: correct and improve the model property of dt files dt-bindings: xilinx: zynq: Improve boards description dt-bindings: xilinx: zynq: Sort entries alphabetically dt-bindings: Move Paralella board to Xilinx dt-bindings: xilinx: zynq: Add missing boards .../devicetree/bindings/arm/adapteva.txt | 7 - .../devicetree/bindings/arm/xilinx.txt| 30 +++ arch/arm/boot/dts/zynq-cc108.dts | 2 +- arch/arm/boot/dts/zynq-microzed.dts | 4 +-- arch/arm/boot/dts/zynq-parallella.dts | 2 +- arch/arm/boot/dts/zynq-zc702.dts | 2 +- arch/arm/boot/dts/zynq-zc706.dts | 2 +- arch/arm/boot/dts/zynq-zc770-xm010.dts| 2 +- arch/arm/boot/dts/zynq-zc770-xm011.dts| 2 +- arch/arm/boot/dts/zynq-zc770-xm012.dts| 2 +- arch/arm/boot/dts/zynq-zc770-xm013.dts| 2 +- arch/arm/boot/dts/zynq-zed.dts| 4 +-- arch/arm/boot/dts/zynq-zybo-z7.dts| 2 +- arch/arm/boot/dts/zynq-zybo.dts | 2 +- 14 files changed, 39 insertions(+), 26 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/adapteva.txt -- 2.18.0
[PATCH v3 4/6] dt-bindings: xilinx: zynq: Sort entries alphabetically
Sort additional compatible strings (boards) alphabetically by their manufacturer and model number This will help when finding a board because they will be grouped by their manufacturer Signed-off-by: Luis Araneda --- Documentation/devicetree/bindings/arm/xilinx.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt index 4f1759b2bea7..a8e70a794d2e 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.txt +++ b/Documentation/devicetree/bindings/arm/xilinx.txt @@ -8,6 +8,9 @@ Required root node properties: Additional compatible strings: +- Digilent Zybo Z7 board + "digilent,zynq-zybo-z7" + - Xilinx CC108 internal board "xlnx,zynq-cc108" @@ -17,9 +20,6 @@ Additional compatible strings: "xlnx,zynq-zc770-xm012" "xlnx,zynq-zc770-xm013" -- Digilent Zybo Z7 board - "digilent,zynq-zybo-z7" - --- Xilinx Zynq UltraScale+ MPSoC Platforms Device Tree Bindings -- 2.18.0
[PATCH v3 3/6] dt-bindings: xilinx: zynq: Improve boards description
Change the description of some boards to make it similar to the value of the model property from their respective device-tree, using the format " " Signed-off-by: Luis Araneda --- Documentation/devicetree/bindings/arm/xilinx.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt index b9043bc35c14..4f1759b2bea7 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.txt +++ b/Documentation/devicetree/bindings/arm/xilinx.txt @@ -8,10 +8,10 @@ Required root node properties: Additional compatible strings: -- Xilinx internal board cc108 +- Xilinx CC108 internal board "xlnx,zynq-cc108" -- Xilinx internal board zc770 with different FMC cards +- Xilinx ZC770 internal board, with different FMC cards "xlnx,zynq-zc770-xm010" "xlnx,zynq-zc770-xm011" "xlnx,zynq-zc770-xm012" -- 2.18.0
[PATCH v3 1/6] arm: dts: zynq: Set correct manufacturer for ZedBoard and MicroZed boards
Both boards are made by Avnet, Inc. So add an additional
value to the compatible property
Signed-off-by: Luis Araneda
---
arch/arm/boot/dts/zynq-microzed.dts | 2 +-
arch/arm/boot/dts/zynq-zed.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-microzed.dts
b/arch/arm/boot/dts/zynq-microzed.dts
index aa4a0b6defb8..574ef2276182 100644
--- a/arch/arm/boot/dts/zynq-microzed.dts
+++ b/arch/arm/boot/dts/zynq-microzed.dts
@@ -8,7 +8,7 @@
/ {
model = "Zynq MicroZED Development Board";
- compatible = "xlnx,zynq-microzed", "xlnx,zynq-7000";
+ compatible = "avnet,zynq-microzed", "xlnx,zynq-microzed",
"xlnx,zynq-7000";
aliases {
ethernet0 =
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 53c6883ce1f6..595022487965 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -8,7 +8,7 @@
/ {
model = "Zynq Zed Development Board";
- compatible = "xlnx,zynq-zed", "xlnx,zynq-7000";
+ compatible = "avnet,zynq-zed", "xlnx,zynq-zed", "xlnx,zynq-7000";
aliases {
ethernet0 =
--
2.18.0
[PATCH v3 2/6] arm: dts: zynq: correct and improve the model property of dt files
Replace the current value of the model property by a more accurate
description of each board (which includes the manufacturer), as some
of the boards had the same value ("Xilinx Zynq")
Signed-off-by: Luis Araneda
---
arch/arm/boot/dts/zynq-cc108.dts | 2 +-
arch/arm/boot/dts/zynq-microzed.dts| 2 +-
arch/arm/boot/dts/zynq-parallella.dts | 2 +-
arch/arm/boot/dts/zynq-zc702.dts | 2 +-
arch/arm/boot/dts/zynq-zc706.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm010.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm011.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm012.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm013.dts | 2 +-
arch/arm/boot/dts/zynq-zed.dts | 2 +-
arch/arm/boot/dts/zynq-zybo-z7.dts | 2 +-
arch/arm/boot/dts/zynq-zybo.dts| 2 +-
12 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-cc108.dts b/arch/arm/boot/dts/zynq-cc108.dts
index 1a0f631c1d8d..8b9ab9bba23b 100644
--- a/arch/arm/boot/dts/zynq-cc108.dts
+++ b/arch/arm/boot/dts/zynq-cc108.dts
@@ -12,8 +12,8 @@
/include/ "zynq-7000.dtsi"
/ {
+ model = "Xilinx CC108 board";
compatible = "xlnx,zynq-cc108", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
ethernet0 =
diff --git a/arch/arm/boot/dts/zynq-microzed.dts
b/arch/arm/boot/dts/zynq-microzed.dts
index 574ef2276182..6ed84fb15902 100644
--- a/arch/arm/boot/dts/zynq-microzed.dts
+++ b/arch/arm/boot/dts/zynq-microzed.dts
@@ -7,7 +7,7 @@
/include/ "zynq-7000.dtsi"
/ {
- model = "Zynq MicroZED Development Board";
+ model = "Avnet MicroZed board";
compatible = "avnet,zynq-microzed", "xlnx,zynq-microzed",
"xlnx,zynq-7000";
aliases {
diff --git a/arch/arm/boot/dts/zynq-parallella.dts
b/arch/arm/boot/dts/zynq-parallella.dts
index c05f4b67d4c1..54592aeb92b9 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -12,7 +12,7 @@
/include/ "zynq-7000.dtsi"
/ {
- model = "Adapteva Parallella Board";
+ model = "Adapteva Parallella board";
compatible = "adapteva,parallella", "xlnx,zynq-7000";
aliases {
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index f2330b0cb63d..3f84b94db995 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -7,7 +7,7 @@
#include "zynq-7000.dtsi"
/ {
- model = "Zynq ZC702 Development Board";
+ model = "Xilinx ZC702 board";
compatible = "xlnx,zynq-zc702", "xlnx,zynq-7000";
aliases {
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index 3ad1260ff2a1..a15908cacbcf 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -7,7 +7,7 @@
#include "zynq-7000.dtsi"
/ {
- model = "Zynq ZC706 Development Board";
+ model = "Xilinx ZC706 board";
compatible = "xlnx,zynq-zc706", "xlnx,zynq-7000";
aliases {
diff --git a/arch/arm/boot/dts/zynq-zc770-xm010.dts
b/arch/arm/boot/dts/zynq-zc770-xm010.dts
index 6884f1ad66b7..0e1bfdd3421f 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm010.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm010.dts
@@ -8,8 +8,8 @@
#include "zynq-7000.dtsi"
/ {
+ model = "Xilinx ZC770 XM010 board";
compatible = "xlnx,zynq-zc770-xm010", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
ethernet0 =
diff --git a/arch/arm/boot/dts/zynq-zc770-xm011.dts
b/arch/arm/boot/dts/zynq-zc770-xm011.dts
index b78883cee96a..b7f65862c022 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm011.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm011.dts
@@ -8,8 +8,8 @@
#include "zynq-7000.dtsi"
/ {
+ model = "Xilinx ZC770 XM011 board";
compatible = "xlnx,zynq-zc770-xm011", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
i2c0 =
diff --git a/arch/arm/boot/dts/zynq-zc770-xm012.dts
b/arch/arm/boot/dts/zynq-zc770-xm012.dts
index c3169d63600d..d2359b789eb8 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm012.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm012.dts
@@ -8,8 +8,8 @@
#include "zynq-7000.dtsi"
/ {
+ model = "Xilinx ZC770 XM012 board";
compatible = "xlnx,zynq-zc770-xm012", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
i2c0 =
diff --git a/arch/arm/boot/dts/zynq-zc770-xm013.dts
b/arch/arm/boot/dts/zynq-zc770-xm013.dts
index 8bb66859d774..651913f1afa2 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm013.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm013.dts
@@ -8,8 +8,8 @@
#include "zynq-7000.dtsi"
/ {
+ model = "Xilinx ZC770 XM013 board";
compatible = "xlnx,zynq-zc770-xm013", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
ethernet0 =
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 595022487965..3a4ae51ca4da 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++
[PATCH v3 3/6] dt-bindings: xilinx: zynq: Improve boards description
Change the description of some boards to make it similar to the value of the model property from their respective device-tree, using the format " " Signed-off-by: Luis Araneda --- Documentation/devicetree/bindings/arm/xilinx.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt index b9043bc35c14..4f1759b2bea7 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.txt +++ b/Documentation/devicetree/bindings/arm/xilinx.txt @@ -8,10 +8,10 @@ Required root node properties: Additional compatible strings: -- Xilinx internal board cc108 +- Xilinx CC108 internal board "xlnx,zynq-cc108" -- Xilinx internal board zc770 with different FMC cards +- Xilinx ZC770 internal board, with different FMC cards "xlnx,zynq-zc770-xm010" "xlnx,zynq-zc770-xm011" "xlnx,zynq-zc770-xm012" -- 2.18.0
[PATCH v3 1/6] arm: dts: zynq: Set correct manufacturer for ZedBoard and MicroZed boards
Both boards are made by Avnet, Inc. So add an additional
value to the compatible property
Signed-off-by: Luis Araneda
---
arch/arm/boot/dts/zynq-microzed.dts | 2 +-
arch/arm/boot/dts/zynq-zed.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-microzed.dts
b/arch/arm/boot/dts/zynq-microzed.dts
index aa4a0b6defb8..574ef2276182 100644
--- a/arch/arm/boot/dts/zynq-microzed.dts
+++ b/arch/arm/boot/dts/zynq-microzed.dts
@@ -8,7 +8,7 @@
/ {
model = "Zynq MicroZED Development Board";
- compatible = "xlnx,zynq-microzed", "xlnx,zynq-7000";
+ compatible = "avnet,zynq-microzed", "xlnx,zynq-microzed",
"xlnx,zynq-7000";
aliases {
ethernet0 =
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 53c6883ce1f6..595022487965 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -8,7 +8,7 @@
/ {
model = "Zynq Zed Development Board";
- compatible = "xlnx,zynq-zed", "xlnx,zynq-7000";
+ compatible = "avnet,zynq-zed", "xlnx,zynq-zed", "xlnx,zynq-7000";
aliases {
ethernet0 =
--
2.18.0
[PATCH v3 2/6] arm: dts: zynq: correct and improve the model property of dt files
Replace the current value of the model property by a more accurate
description of each board (which includes the manufacturer), as some
of the boards had the same value ("Xilinx Zynq")
Signed-off-by: Luis Araneda
---
arch/arm/boot/dts/zynq-cc108.dts | 2 +-
arch/arm/boot/dts/zynq-microzed.dts| 2 +-
arch/arm/boot/dts/zynq-parallella.dts | 2 +-
arch/arm/boot/dts/zynq-zc702.dts | 2 +-
arch/arm/boot/dts/zynq-zc706.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm010.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm011.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm012.dts | 2 +-
arch/arm/boot/dts/zynq-zc770-xm013.dts | 2 +-
arch/arm/boot/dts/zynq-zed.dts | 2 +-
arch/arm/boot/dts/zynq-zybo-z7.dts | 2 +-
arch/arm/boot/dts/zynq-zybo.dts| 2 +-
12 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-cc108.dts b/arch/arm/boot/dts/zynq-cc108.dts
index 1a0f631c1d8d..8b9ab9bba23b 100644
--- a/arch/arm/boot/dts/zynq-cc108.dts
+++ b/arch/arm/boot/dts/zynq-cc108.dts
@@ -12,8 +12,8 @@
/include/ "zynq-7000.dtsi"
/ {
+ model = "Xilinx CC108 board";
compatible = "xlnx,zynq-cc108", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
ethernet0 =
diff --git a/arch/arm/boot/dts/zynq-microzed.dts
b/arch/arm/boot/dts/zynq-microzed.dts
index 574ef2276182..6ed84fb15902 100644
--- a/arch/arm/boot/dts/zynq-microzed.dts
+++ b/arch/arm/boot/dts/zynq-microzed.dts
@@ -7,7 +7,7 @@
/include/ "zynq-7000.dtsi"
/ {
- model = "Zynq MicroZED Development Board";
+ model = "Avnet MicroZed board";
compatible = "avnet,zynq-microzed", "xlnx,zynq-microzed",
"xlnx,zynq-7000";
aliases {
diff --git a/arch/arm/boot/dts/zynq-parallella.dts
b/arch/arm/boot/dts/zynq-parallella.dts
index c05f4b67d4c1..54592aeb92b9 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -12,7 +12,7 @@
/include/ "zynq-7000.dtsi"
/ {
- model = "Adapteva Parallella Board";
+ model = "Adapteva Parallella board";
compatible = "adapteva,parallella", "xlnx,zynq-7000";
aliases {
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index f2330b0cb63d..3f84b94db995 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -7,7 +7,7 @@
#include "zynq-7000.dtsi"
/ {
- model = "Zynq ZC702 Development Board";
+ model = "Xilinx ZC702 board";
compatible = "xlnx,zynq-zc702", "xlnx,zynq-7000";
aliases {
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index 3ad1260ff2a1..a15908cacbcf 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -7,7 +7,7 @@
#include "zynq-7000.dtsi"
/ {
- model = "Zynq ZC706 Development Board";
+ model = "Xilinx ZC706 board";
compatible = "xlnx,zynq-zc706", "xlnx,zynq-7000";
aliases {
diff --git a/arch/arm/boot/dts/zynq-zc770-xm010.dts
b/arch/arm/boot/dts/zynq-zc770-xm010.dts
index 6884f1ad66b7..0e1bfdd3421f 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm010.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm010.dts
@@ -8,8 +8,8 @@
#include "zynq-7000.dtsi"
/ {
+ model = "Xilinx ZC770 XM010 board";
compatible = "xlnx,zynq-zc770-xm010", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
ethernet0 =
diff --git a/arch/arm/boot/dts/zynq-zc770-xm011.dts
b/arch/arm/boot/dts/zynq-zc770-xm011.dts
index b78883cee96a..b7f65862c022 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm011.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm011.dts
@@ -8,8 +8,8 @@
#include "zynq-7000.dtsi"
/ {
+ model = "Xilinx ZC770 XM011 board";
compatible = "xlnx,zynq-zc770-xm011", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
i2c0 =
diff --git a/arch/arm/boot/dts/zynq-zc770-xm012.dts
b/arch/arm/boot/dts/zynq-zc770-xm012.dts
index c3169d63600d..d2359b789eb8 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm012.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm012.dts
@@ -8,8 +8,8 @@
#include "zynq-7000.dtsi"
/ {
+ model = "Xilinx ZC770 XM012 board";
compatible = "xlnx,zynq-zc770-xm012", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
i2c0 =
diff --git a/arch/arm/boot/dts/zynq-zc770-xm013.dts
b/arch/arm/boot/dts/zynq-zc770-xm013.dts
index 8bb66859d774..651913f1afa2 100644
--- a/arch/arm/boot/dts/zynq-zc770-xm013.dts
+++ b/arch/arm/boot/dts/zynq-zc770-xm013.dts
@@ -8,8 +8,8 @@
#include "zynq-7000.dtsi"
/ {
+ model = "Xilinx ZC770 XM013 board";
compatible = "xlnx,zynq-zc770-xm013", "xlnx,zynq-7000";
- model = "Xilinx Zynq";
aliases {
ethernet0 =
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index 595022487965..3a4ae51ca4da 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi Jassi, > -Original Message- > From: Jassi Brar [mailto:jassisinghb...@gmail.com] > Sent: Thursday, July 12, 2018 1:01 AM > To: A.s. Dong > Cc: Sascha Hauer ; linux-arm- > ker...@lists.infradead.org; donga...@gmail.com; linux- > ker...@vger.kernel.org; Oleksij Rempel ; dl- > linux-imx ; ker...@pengutronix.de; Fabio Estevam > ; shawn...@kernel.org > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > bcm seems is using peek to receive data, not only checking the data > > availability, right? > > drivers/mailbox/bcm-flexrm-mailbox.c > > > As I said, if fetching data from remote don't need to sleep, you can call > mbox_chan_received_data() from peek(). Otherwise not. Got it. So it seems work for i.MX. Thanks. Regards Dong Aisheng
RE: [PATCH V4 3/5] mailbox: imx: add imx mu support
Hi Jassi, > -Original Message- > From: Jassi Brar [mailto:jassisinghb...@gmail.com] > Sent: Thursday, July 12, 2018 1:01 AM > To: A.s. Dong > Cc: Sascha Hauer ; linux-arm- > ker...@lists.infradead.org; donga...@gmail.com; linux- > ker...@vger.kernel.org; Oleksij Rempel ; dl- > linux-imx ; ker...@pengutronix.de; Fabio Estevam > ; shawn...@kernel.org > Subject: Re: [PATCH V4 3/5] mailbox: imx: add imx mu support > > > > bcm seems is using peek to receive data, not only checking the data > > availability, right? > > drivers/mailbox/bcm-flexrm-mailbox.c > > > As I said, if fetching data from remote don't need to sleep, you can call > mbox_chan_received_data() from peek(). Otherwise not. Got it. So it seems work for i.MX. Thanks. Regards Dong Aisheng
[PATCH 0/5] fsi: Coldfire coprocessor offload
This series implements support for offloading the FSI protocol bitbanging to the ColdFire secondary core of the Aspeed SoCs. The result increases FSI performance by a factor of 4, and on systems that don't support async FSI clock, provide much more regular and continuous clocking which helps reliability. This series is much smaller than the previous submissions as I already merged all the "preparatory" work into the FSI tree. This is now strictly the coldfire support and is now only waiting for ack of the DT bindings (and whatever other review comments might come my way) before I put it into the FSI tree and sends it to Greg. There are two dependencies to be able to build/use this. The above prep work: https://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git/log/ And the Aspeed GPIO driver changes for handling with GPIO lines ownership and handshaking. The patches have been merged into the GPIO tree and a dedicated immutable topic branch and can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=ib-aspeed Finally, the driver needs a machine specific firmware file. The firwmare is open source and available at: https://github.com/ozbenh/cf-fsi I will submit it to linux-firmware if there's enough popular demand ;-) v2. Fix misuse of devm_kzalloc for objects containing a struct device in fsi-master-gpio and fsi-master-ast-cf (similar fixes for the various FSI drivers will come later a part of rework to move away from misc devs). v3. Sparse fix and updated DT bindings as per Rob's comments.
[PATCH 0/5] fsi: Coldfire coprocessor offload
This series implements support for offloading the FSI protocol bitbanging to the ColdFire secondary core of the Aspeed SoCs. The result increases FSI performance by a factor of 4, and on systems that don't support async FSI clock, provide much more regular and continuous clocking which helps reliability. This series is much smaller than the previous submissions as I already merged all the "preparatory" work into the FSI tree. This is now strictly the coldfire support and is now only waiting for ack of the DT bindings (and whatever other review comments might come my way) before I put it into the FSI tree and sends it to Greg. There are two dependencies to be able to build/use this. The above prep work: https://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git/log/ And the Aspeed GPIO driver changes for handling with GPIO lines ownership and handshaking. The patches have been merged into the GPIO tree and a dedicated immutable topic branch and can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=ib-aspeed Finally, the driver needs a machine specific firmware file. The firwmare is open source and available at: https://github.com/ozbenh/cf-fsi I will submit it to linux-firmware if there's enough popular demand ;-) v2. Fix misuse of devm_kzalloc for objects containing a struct device in fsi-master-gpio and fsi-master-ast-cf (similar fixes for the various FSI drivers will come later a part of rework to move away from misc devs). v3. Sparse fix and updated DT bindings as per Rob's comments.
[PATCH] arm64: neon: Fix function may_use_simd() return error status
From: Yandong Zhao
It does not matter if the caller of may_use_simd() migrates to
another cpu after the call, but it is still important that the
kernel_neon_busy percpu instance that is read matches the cpu the
task is running on at the time of the read.
This means that raw_cpu_read() is not sufficient. kernel_neon_busy
may appear true if the caller migrates during the execution of
raw_cpu_read() and the next task to be scheduled in on the initial
cpu calls kernel_neon_begin().
This patch replaces raw_cpu_read() with this_cpu_read() to protect
against this race.
Fixes: cb84d11e1625 ("arm64: neon: Remove support for nested or hardirq
kernel-mode NEON")
Acked-by: Ard Biesheuvel
Reviewed-by: Dave Martin
Reviewed-by: Mark Rutland
Signed-off-by: Yandong Zhao
---
arch/arm64/include/asm/simd.h | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/simd.h b/arch/arm64/include/asm/simd.h
index fa8b3fe..6495cc5 100644
--- a/arch/arm64/include/asm/simd.h
+++ b/arch/arm64/include/asm/simd.h
@@ -29,20 +29,15 @@
static __must_check inline bool may_use_simd(void)
{
/*
-* The raw_cpu_read() is racy if called with preemption enabled.
-* This is not a bug: kernel_neon_busy is only set when
-* preemption is disabled, so we cannot migrate to another CPU
-* while it is set, nor can we migrate to a CPU where it is set.
-* So, if we find it clear on some CPU then we're guaranteed to
-* find it clear on any CPU we could migrate to.
-*
-* If we are in between kernel_neon_begin()...kernel_neon_end(),
-* the flag will be set, but preemption is also disabled, so we
-* can't migrate to another CPU and spuriously see it become
-* false.
+* kernel_neon_busy is only set while preemption is disabled,
+* and is clear whenever preemption is enabled. Since
+* this_cpu_read() is atomic w.r.t. preemption, kernel_neon_busy
+* cannot change under our feet -- if it's set we cannot be
+* migrated, and if it's clear we cannot be migrated to a CPU
+* where it is set.
*/
return !in_irq() && !irqs_disabled() && !in_nmi() &&
- !raw_cpu_read(kernel_neon_busy);
+ !this_cpu_read(kernel_neon_busy);
}
#else /* ! CONFIG_KERNEL_MODE_NEON */
--
1.9.1
[PATCH] arm64: neon: Fix function may_use_simd() return error status
From: Yandong Zhao
It does not matter if the caller of may_use_simd() migrates to
another cpu after the call, but it is still important that the
kernel_neon_busy percpu instance that is read matches the cpu the
task is running on at the time of the read.
This means that raw_cpu_read() is not sufficient. kernel_neon_busy
may appear true if the caller migrates during the execution of
raw_cpu_read() and the next task to be scheduled in on the initial
cpu calls kernel_neon_begin().
This patch replaces raw_cpu_read() with this_cpu_read() to protect
against this race.
Fixes: cb84d11e1625 ("arm64: neon: Remove support for nested or hardirq
kernel-mode NEON")
Acked-by: Ard Biesheuvel
Reviewed-by: Dave Martin
Reviewed-by: Mark Rutland
Signed-off-by: Yandong Zhao
---
arch/arm64/include/asm/simd.h | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/simd.h b/arch/arm64/include/asm/simd.h
index fa8b3fe..6495cc5 100644
--- a/arch/arm64/include/asm/simd.h
+++ b/arch/arm64/include/asm/simd.h
@@ -29,20 +29,15 @@
static __must_check inline bool may_use_simd(void)
{
/*
-* The raw_cpu_read() is racy if called with preemption enabled.
-* This is not a bug: kernel_neon_busy is only set when
-* preemption is disabled, so we cannot migrate to another CPU
-* while it is set, nor can we migrate to a CPU where it is set.
-* So, if we find it clear on some CPU then we're guaranteed to
-* find it clear on any CPU we could migrate to.
-*
-* If we are in between kernel_neon_begin()...kernel_neon_end(),
-* the flag will be set, but preemption is also disabled, so we
-* can't migrate to another CPU and spuriously see it become
-* false.
+* kernel_neon_busy is only set while preemption is disabled,
+* and is clear whenever preemption is enabled. Since
+* this_cpu_read() is atomic w.r.t. preemption, kernel_neon_busy
+* cannot change under our feet -- if it's set we cannot be
+* migrated, and if it's clear we cannot be migrated to a CPU
+* where it is set.
*/
return !in_irq() && !irqs_disabled() && !in_nmi() &&
- !raw_cpu_read(kernel_neon_busy);
+ !this_cpu_read(kernel_neon_busy);
}
#else /* ! CONFIG_KERNEL_MODE_NEON */
--
1.9.1
Re: [PATCH v9 4/7] tracepoint: Make rcuidle tracepoint callers use SRCU
On Wed, 11 Jul 2018 13:52:49 -0700
Joel Fernandes wrote:
> > #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
> > extern struct tracepoint __tracepoint_##name; \
> > static inline void trace_##name(proto) \
> > { \
> > if (static_key_false(&__tracepoint_##name.key)) \
> > __DO_TRACE(&__tracepoint_##name,\
> > TP_PROTO(data_proto), \
> > TP_ARGS(data_args), \
> > TP_CONDITION(cond), 0); \
> > if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { \
> > rcu_read_lock_sched_notrace(); \
> > rcu_dereference_sched(__tracepoint_##name.funcs);\
> > rcu_read_unlock_sched_notrace();\
> > } \
> > }
> >
> > Because lockdep would only trigger warnings when the tracepoint was
> > enabled and used in a place it shouldn't be, we added the above
> > IS_ENABLED(CONFIG_LOCKDEP) part to test regardless if the the
> > tracepoint was enabled or not. Because we do this, we don't need to
> > have the test in the __DO_TRACE() code itself. That means we can clean
> > up the code as per Peter's suggestion.
>
> Sounds good, I'm Ok with making this change.
>
> Just to clarify, are you proposing to change the rcu_dereference_sched to
> rcu_dereference_raw in both __DECLARE_TRACE and __DO_TRACE?
No, just in __DO_TRACE(). The rcu_dereference_sched() above in
__DECLARE_TRACE() in the if (IS_ENABLED(CONFIG_LOCKDEP) block is
required to show the warnings if trace_##name() is used wrong, and is
the reason we can use rcu_dereference_raw() in __DO_TRACE() in the
first place ;-)
This brings up another point. We should probably add to
__DECLARE_TRACE_RCU() this:
#ifndef MODULE
#define __DECLARE_TRACE_RCU(name, proto, args, cond, data_proto, data_args) \
static inline void trace_##name##_rcuidle(proto)\
{ \
if (static_key_false(&__tracepoint_##name.key)) \
__DO_TRACE(&__tracepoint_##name,\
TP_PROTO(data_proto), \
TP_ARGS(data_args), \
TP_CONDITION(cond), 1); \
+ if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { \
+ int idx;\
+ idx = srcu_read_lock_notrace(_srcu); \
+ srcu_dereference_notrace(__tracepoint_##name.funcs, \
+ _srcu); \
+ srcu_read_unlock_notrace(_srcu, idx); \
+ } \
}
#else
So that lockdep works with trace_##name##__rcuidle() when the trace
event is not enabled.
But that should be a separate patch and not part of this series. I may
write that up tomorrow.
-- Steve
Re: [PATCH v9 4/7] tracepoint: Make rcuidle tracepoint callers use SRCU
On Wed, 11 Jul 2018 13:52:49 -0700
Joel Fernandes wrote:
> > #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
> > extern struct tracepoint __tracepoint_##name; \
> > static inline void trace_##name(proto) \
> > { \
> > if (static_key_false(&__tracepoint_##name.key)) \
> > __DO_TRACE(&__tracepoint_##name,\
> > TP_PROTO(data_proto), \
> > TP_ARGS(data_args), \
> > TP_CONDITION(cond), 0); \
> > if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { \
> > rcu_read_lock_sched_notrace(); \
> > rcu_dereference_sched(__tracepoint_##name.funcs);\
> > rcu_read_unlock_sched_notrace();\
> > } \
> > }
> >
> > Because lockdep would only trigger warnings when the tracepoint was
> > enabled and used in a place it shouldn't be, we added the above
> > IS_ENABLED(CONFIG_LOCKDEP) part to test regardless if the the
> > tracepoint was enabled or not. Because we do this, we don't need to
> > have the test in the __DO_TRACE() code itself. That means we can clean
> > up the code as per Peter's suggestion.
>
> Sounds good, I'm Ok with making this change.
>
> Just to clarify, are you proposing to change the rcu_dereference_sched to
> rcu_dereference_raw in both __DECLARE_TRACE and __DO_TRACE?
No, just in __DO_TRACE(). The rcu_dereference_sched() above in
__DECLARE_TRACE() in the if (IS_ENABLED(CONFIG_LOCKDEP) block is
required to show the warnings if trace_##name() is used wrong, and is
the reason we can use rcu_dereference_raw() in __DO_TRACE() in the
first place ;-)
This brings up another point. We should probably add to
__DECLARE_TRACE_RCU() this:
#ifndef MODULE
#define __DECLARE_TRACE_RCU(name, proto, args, cond, data_proto, data_args) \
static inline void trace_##name##_rcuidle(proto)\
{ \
if (static_key_false(&__tracepoint_##name.key)) \
__DO_TRACE(&__tracepoint_##name,\
TP_PROTO(data_proto), \
TP_ARGS(data_args), \
TP_CONDITION(cond), 1); \
+ if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { \
+ int idx;\
+ idx = srcu_read_lock_notrace(_srcu); \
+ srcu_dereference_notrace(__tracepoint_##name.funcs, \
+ _srcu); \
+ srcu_read_unlock_notrace(_srcu, idx); \
+ } \
}
#else
So that lockdep works with trace_##name##__rcuidle() when the trace
event is not enabled.
But that should be a separate patch and not part of this series. I may
write that up tomorrow.
-- Steve
Re: [patch 7/7] x86/kvmclock: Switch kvmclock data to a PER_CPU variable
> /* Aligned to page sizes to match whats mapped via vsyscalls to userspace */ > #define HV_CLOCK_SIZE (sizeof(struct pvclock_vsyscall_time_info) * NR_CPUS) HV_CLOCK_SIZE is not used anywhere anymore, can be deleted. > +#define HVC_BOOT_ARRAY_SIZE \ > + (PAGE_SIZE / sizeof(struct pvclock_vsyscall_time_info)) This works, because sizeof(struct pvclock_vsyscall_time_info)) == 64 bytes, but static assert that verifies that IS_ALIGNED(PAGESIZE, sizeof(struct pvclock_vsyscall_time_info)) would guarantee that no random data is ever exposed to vdso. Otherwise looks good to me: Reviewed-by: Pavel Tatashin
Re: [patch 7/7] x86/kvmclock: Switch kvmclock data to a PER_CPU variable
> /* Aligned to page sizes to match whats mapped via vsyscalls to userspace */ > #define HV_CLOCK_SIZE (sizeof(struct pvclock_vsyscall_time_info) * NR_CPUS) HV_CLOCK_SIZE is not used anywhere anymore, can be deleted. > +#define HVC_BOOT_ARRAY_SIZE \ > + (PAGE_SIZE / sizeof(struct pvclock_vsyscall_time_info)) This works, because sizeof(struct pvclock_vsyscall_time_info)) == 64 bytes, but static assert that verifies that IS_ALIGNED(PAGESIZE, sizeof(struct pvclock_vsyscall_time_info)) would guarantee that no random data is ever exposed to vdso. Otherwise looks good to me: Reviewed-by: Pavel Tatashin
Re: [PATCH] console: Replace #if 1 with a bool to ignore WARN_CONSOLE_UNLOCKED()
On Thu, 12 Jul 2018 10:58:48 +0900 Sergey Senozhatsky wrote: > On (07/11/18 15:17), Steven Rostedt wrote: > > +bool ignore_console_lock_warning __read_mostly; > > +EXPORT_SYMBOL(ignore_console_lock_warning); > > OK. So, to recap, > We made is_console_locked() EXPORT_SYMBOL recently [it's still in linux-next], > so people could use WARN_CONSOLE_UNLOCKED in more places; this made other > people unhappy, so now we add another EXPORT_SYMBOL to the picture, which will > disable those newly added WARN_CONSOLE_UNLOCKED and make other people happy > again. Note, it only made people that added a module parameter that disables grabbing the console lock in the first place for debugging purposes only. The added WARN_CONSOLE_UNLOCKED() are good. Nobody complaining that they exist. They are complaining that it breaks one of their debugging work flows, and need to disable it when they are doing so. > > This makes me wonder - do we want to add more WARN_CONSOLE_UNLOCKED in the > first place? :) I would say yes. > > Other than that, the patch looks OK to me I guess. I'm not super happy with > more printk EXPORT_SYMBOL-s, frankly speaking, I'm not entirely in love with > the "add a bool flag to suppress warn print outs which we added in the > previous patch" direction, but if you guys want/need it... I could add a comment explaining why it exists. Something like: /* * Set this is you need to quiet WARN_CONSOLE_UNLOCKED() for debugging * purposes. */ > Probably I'm just dramatizing it, as usual ;) > The removal of "#if 1" is definitely nice. Yeah, that had to go regardless. > > Let's hear from Petr. Sure. -- Steve
Re: [PATCH] console: Replace #if 1 with a bool to ignore WARN_CONSOLE_UNLOCKED()
On Thu, 12 Jul 2018 10:58:48 +0900 Sergey Senozhatsky wrote: > On (07/11/18 15:17), Steven Rostedt wrote: > > +bool ignore_console_lock_warning __read_mostly; > > +EXPORT_SYMBOL(ignore_console_lock_warning); > > OK. So, to recap, > We made is_console_locked() EXPORT_SYMBOL recently [it's still in linux-next], > so people could use WARN_CONSOLE_UNLOCKED in more places; this made other > people unhappy, so now we add another EXPORT_SYMBOL to the picture, which will > disable those newly added WARN_CONSOLE_UNLOCKED and make other people happy > again. Note, it only made people that added a module parameter that disables grabbing the console lock in the first place for debugging purposes only. The added WARN_CONSOLE_UNLOCKED() are good. Nobody complaining that they exist. They are complaining that it breaks one of their debugging work flows, and need to disable it when they are doing so. > > This makes me wonder - do we want to add more WARN_CONSOLE_UNLOCKED in the > first place? :) I would say yes. > > Other than that, the patch looks OK to me I guess. I'm not super happy with > more printk EXPORT_SYMBOL-s, frankly speaking, I'm not entirely in love with > the "add a bool flag to suppress warn print outs which we added in the > previous patch" direction, but if you guys want/need it... I could add a comment explaining why it exists. Something like: /* * Set this is you need to quiet WARN_CONSOLE_UNLOCKED() for debugging * purposes. */ > Probably I'm just dramatizing it, as usual ;) > The removal of "#if 1" is definitely nice. Yeah, that had to go regardless. > > Let's hear from Petr. Sure. -- Steve
Re: [PATCH v2 2/2] ARM: dts: am335x: add am335x-sancloud-bbe board support
On Wed, Jul 11, 2018 at 8:31 AM, Tony Lindgren wrote:
> * Koen Kooi [180711 07:36]:
>> +_opp_table {
>> + /*
>> + * All PG 2.0 silicon may not support 1GHz but some of the early
>> + * BeagleBone Blacks have PG 2.0 silicon which is guaranteed
>> + * to support 1GHz OPP so enable it for PG 2.0 on this board.
>> + */
>> + oppnitro-10 {
>> + opp-supported-hw = <0x06 0x0100>;
>> + };
>> +};
>
> Is the above valid for new boards or should it be just
> dropped? Or is the comment just out of date?
For SanCloud, this can be dropped, they got normal 1Ghz parts from TI.
and they aren't using the Octavo SIP which didn't have the 1Ghz efuse set..
So just the normal am335x errata, nothing special required in it's dts...
Regards,
--
Robert Nelson
https://rcn-ee.com/
Re: [PATCH v2 2/2] ARM: dts: am335x: add am335x-sancloud-bbe board support
On Wed, Jul 11, 2018 at 8:31 AM, Tony Lindgren wrote:
> * Koen Kooi [180711 07:36]:
>> +_opp_table {
>> + /*
>> + * All PG 2.0 silicon may not support 1GHz but some of the early
>> + * BeagleBone Blacks have PG 2.0 silicon which is guaranteed
>> + * to support 1GHz OPP so enable it for PG 2.0 on this board.
>> + */
>> + oppnitro-10 {
>> + opp-supported-hw = <0x06 0x0100>;
>> + };
>> +};
>
> Is the above valid for new boards or should it be just
> dropped? Or is the comment just out of date?
For SanCloud, this can be dropped, they got normal 1Ghz parts from TI.
and they aren't using the Octavo SIP which didn't have the 1Ghz efuse set..
So just the normal am335x errata, nothing special required in it's dts...
Regards,
--
Robert Nelson
https://rcn-ee.com/
[GIT PULL] FSI updates round 2 for 4.19
Hi Greg ! This is the second round of updates of the FSI stack. These comprise of: - Some build fixes detected with COMPILE_TEST when used on "other" archs - Sparse warning fixes - Some object lifetime fixes - A new feature to control some of the protocol delays - Overheaul of the "SCOM" driver used to access the POWER processor internal SCOM bus. - Preparatory work for the new ColdFire coprocessor based FSI master work which, along some other newer work is still going through the last few rounds of polish and DT bindings reviews. The following changes since commit 9f4a8a2d7f9d71093f41c4bb0ef8707e8145bad3: fsi/sbefifo: Add driver for the SBE FIFO (2018-06-12 14:05:39 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git tags/fsi-updates-2018-07-12 for you to fetch changes up to fea9cf321c916e9372874e6f2af1bf0b5beb89fb: fsi: Move various master definitions to a common header (2018-07-12 12:06:02 +1000) Benjamin Herrenschmidt (17): fsi: sbefifo: Remove unneeded semicolon fsi: scom: Add mutex around FSI2PIB accesses fsi: scom: Whitespace fixes fsi: scom: Fixup endian annotations fsi: scom: Add register definitions fsi: scom: Major overhaul fsi: sbefifo: Fix checker warning about late NULL check fsi: Move code around to avoid forward declaration fsi: Add mechanism to set the tSendDelay and tEchoDelay values fsi: master-gpio: Rename and adjust send delay fsi: master-gpio: Add support for link_config fsi: master-gpio: Add more tracepoints fsi: master-gpio: Remove unused definitions fsi: master-gpio: Remove "GPIO" prefix on some definitions fsi: Don't use device_unregister() in fsi_master_register() fsi: master-gpio: Add missing release function fsi: Move various master definitions to a common header Eddie James (1): fsi: sbefifo: Add missing mutex_unlock Guenter Roeck (1): fsi/sbefifo: Add dependency on OF_ADDRESS Joel Stanley (3): fsi: sbefifo: Fix sparse warnings fsi: master-hub: Fix sparse warnings fsi: core: Fix sparse warnings drivers/fsi/Kconfig| 1 + drivers/fsi/fsi-core.c | 215 +++-- drivers/fsi/fsi-master-gpio.c | 170 --- drivers/fsi/fsi-master-hub.c | 5 +- drivers/fsi/fsi-master.h | 35 + drivers/fsi/fsi-sbefifo.c | 15 +- drivers/fsi/fsi-scom.c | 433 +++--- include/trace/events/fsi_master_gpio.h | 59 include/uapi/linux/fsi.h | 58 9 files changed, 813 insertions(+), 178 deletions(-) create mode 100644 include/uapi/linux/fsi.h
[GIT PULL] FSI updates round 2 for 4.19
Hi Greg ! This is the second round of updates of the FSI stack. These comprise of: - Some build fixes detected with COMPILE_TEST when used on "other" archs - Sparse warning fixes - Some object lifetime fixes - A new feature to control some of the protocol delays - Overheaul of the "SCOM" driver used to access the POWER processor internal SCOM bus. - Preparatory work for the new ColdFire coprocessor based FSI master work which, along some other newer work is still going through the last few rounds of polish and DT bindings reviews. The following changes since commit 9f4a8a2d7f9d71093f41c4bb0ef8707e8145bad3: fsi/sbefifo: Add driver for the SBE FIFO (2018-06-12 14:05:39 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git tags/fsi-updates-2018-07-12 for you to fetch changes up to fea9cf321c916e9372874e6f2af1bf0b5beb89fb: fsi: Move various master definitions to a common header (2018-07-12 12:06:02 +1000) Benjamin Herrenschmidt (17): fsi: sbefifo: Remove unneeded semicolon fsi: scom: Add mutex around FSI2PIB accesses fsi: scom: Whitespace fixes fsi: scom: Fixup endian annotations fsi: scom: Add register definitions fsi: scom: Major overhaul fsi: sbefifo: Fix checker warning about late NULL check fsi: Move code around to avoid forward declaration fsi: Add mechanism to set the tSendDelay and tEchoDelay values fsi: master-gpio: Rename and adjust send delay fsi: master-gpio: Add support for link_config fsi: master-gpio: Add more tracepoints fsi: master-gpio: Remove unused definitions fsi: master-gpio: Remove "GPIO" prefix on some definitions fsi: Don't use device_unregister() in fsi_master_register() fsi: master-gpio: Add missing release function fsi: Move various master definitions to a common header Eddie James (1): fsi: sbefifo: Add missing mutex_unlock Guenter Roeck (1): fsi/sbefifo: Add dependency on OF_ADDRESS Joel Stanley (3): fsi: sbefifo: Fix sparse warnings fsi: master-hub: Fix sparse warnings fsi: core: Fix sparse warnings drivers/fsi/Kconfig| 1 + drivers/fsi/fsi-core.c | 215 +++-- drivers/fsi/fsi-master-gpio.c | 170 --- drivers/fsi/fsi-master-hub.c | 5 +- drivers/fsi/fsi-master.h | 35 + drivers/fsi/fsi-sbefifo.c | 15 +- drivers/fsi/fsi-scom.c | 433 +++--- include/trace/events/fsi_master_gpio.h | 59 include/uapi/linux/fsi.h | 58 9 files changed, 813 insertions(+), 178 deletions(-) create mode 100644 include/uapi/linux/fsi.h
Re: [PATCH] ring_buffer: Update logging to use single line output
On Fri, 11 May 2018 14:39:18 -0700
Joe Perches wrote:
> With a possible change to pr_fmt coming, the logging output can
> become unbalanced when an initial line has a prefix and subsequent
> lines do not when a multiple line pr_ is emitted.
>
> Fix it by emitting a single line.
>
> Miscellanea:
>
> o Convert consecutive tests of total_lost and !total_lost to if/else
I just noticed this patch. Please don't send patches Cc'd to other
threads. They need to start a new thread, otherwise, like this one, it
will most likely be lost.
If you want this applied still, please resend it properly.
-- Steve
>
> Signed-off-by: Joe Perches
> ---
> kernel/trace/ring_buffer.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index c9cb9767d49b..ee74494a2da3 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -5132,10 +5132,9 @@ static __init int test_ringbuffer(void)
> pr_info("total events: %ld\n", total_lost +
> total_read);
> pr_info(" recorded len bytes: %ld\n", total_len);
> pr_info(" recorded size bytes: %ld\n", total_size);
> - if (total_lost)
> - pr_info(" With dropped events, record len and size may
> not match\n"
> - " alloced and written from above\n");
> - if (!total_lost) {
> + if (total_lost) {
> + pr_info(" With dropped events, record len and size may
> not match alloced and written from above\n");
> + } else {
> if (RB_WARN_ON(buffer, total_len != total_alloc ||
> total_size != total_written))
> break;
Re: [PATCH] ring_buffer: Update logging to use single line output
On Fri, 11 May 2018 14:39:18 -0700
Joe Perches wrote:
> With a possible change to pr_fmt coming, the logging output can
> become unbalanced when an initial line has a prefix and subsequent
> lines do not when a multiple line pr_ is emitted.
>
> Fix it by emitting a single line.
>
> Miscellanea:
>
> o Convert consecutive tests of total_lost and !total_lost to if/else
I just noticed this patch. Please don't send patches Cc'd to other
threads. They need to start a new thread, otherwise, like this one, it
will most likely be lost.
If you want this applied still, please resend it properly.
-- Steve
>
> Signed-off-by: Joe Perches
> ---
> kernel/trace/ring_buffer.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index c9cb9767d49b..ee74494a2da3 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -5132,10 +5132,9 @@ static __init int test_ringbuffer(void)
> pr_info("total events: %ld\n", total_lost +
> total_read);
> pr_info(" recorded len bytes: %ld\n", total_len);
> pr_info(" recorded size bytes: %ld\n", total_size);
> - if (total_lost)
> - pr_info(" With dropped events, record len and size may
> not match\n"
> - " alloced and written from above\n");
> - if (!total_lost) {
> + if (total_lost) {
> + pr_info(" With dropped events, record len and size may
> not match alloced and written from above\n");
> + } else {
> if (RB_WARN_ON(buffer, total_len != total_alloc ||
> total_size != total_written))
> break;
Re: [patch 6/7] x86/kvmclock: Move kvmclock vsyscall param and init to kvmclock
+#include
Can be removed, because as Paolo, noticed X86_HYPER_KVM check is not needed.
> +static int __init kvm_setup_vsyscall_timeinfo(void)
> +{
> +#ifdef CONFIG_X86_64
> + u8 flags;
> +
> + if (!hv_clock || !kvmclock_vsyscall)
> + return 0;
> +
> + flags = pvclock_read_flags(_clock[0].pvti);
> + if (!(flags & PVCLOCK_TSC_STABLE_BIT))
> + return 1;
> +
> + pvclock_set_pvti_cpu0_va(hv_clock);
> + kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
> +#endif
> + return 0;
> +}
> +early_initcall(kvm_setup_vsyscall_timeinfo);
> +
> -
> -int __init kvm_setup_vsyscall_timeinfo(void)
> -{
> -#ifdef CONFIG_X86_64
> - u8 flags;
> -
> - if (!hv_clock)
> - return 0;
> -
> - flags = pvclock_read_flags(_clock[0].pvti);
> - if (!(flags & PVCLOCK_TSC_STABLE_BIT))
> - return 1;
> -
> - pvclock_set_pvti_cpu0_va(hv_clock);
> - kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
> -#endif
> - return 0;
> -}
I am not sure what the point of moving this function. The patch would
be much smaller without it.
Reviewed-by: Pavel Tatashin
Re: [patch 6/7] x86/kvmclock: Move kvmclock vsyscall param and init to kvmclock
+#include
Can be removed, because as Paolo, noticed X86_HYPER_KVM check is not needed.
> +static int __init kvm_setup_vsyscall_timeinfo(void)
> +{
> +#ifdef CONFIG_X86_64
> + u8 flags;
> +
> + if (!hv_clock || !kvmclock_vsyscall)
> + return 0;
> +
> + flags = pvclock_read_flags(_clock[0].pvti);
> + if (!(flags & PVCLOCK_TSC_STABLE_BIT))
> + return 1;
> +
> + pvclock_set_pvti_cpu0_va(hv_clock);
> + kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
> +#endif
> + return 0;
> +}
> +early_initcall(kvm_setup_vsyscall_timeinfo);
> +
> -
> -int __init kvm_setup_vsyscall_timeinfo(void)
> -{
> -#ifdef CONFIG_X86_64
> - u8 flags;
> -
> - if (!hv_clock)
> - return 0;
> -
> - flags = pvclock_read_flags(_clock[0].pvti);
> - if (!(flags & PVCLOCK_TSC_STABLE_BIT))
> - return 1;
> -
> - pvclock_set_pvti_cpu0_va(hv_clock);
> - kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
> -#endif
> - return 0;
> -}
I am not sure what the point of moving this function. The patch would
be much smaller without it.
Reviewed-by: Pavel Tatashin
