Re: am33xx beaglebone mainline status?
On Tue, Nov 27, 2012 at 09:41:51AM +0100, Tim Sander wrote: > Hi > > I have been trying to get the 3.7-rc6 kernel to compile for a beaglebone > board > with device tree but it seems there are still bits missing. Especially it > seems as if the sd card reader and network is not working properly? The CPSW network driver is working in net-next, and so it will be working in v3.8. Don't know about SD, since I only boot with a ramfs. HTH, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: am33xx beaglebone mainline status?
On Tue, Nov 27, 2012 at 03:23:51PM +0100, Yegor Yefremov wrote: > > How do you load your rootfs: embedded into kernel or separately? Separately. I gave up on the embedded option on ARM (IXP) long ago, since I never could getaw it to work. > Do you know if frame buffer is functioning in main line? Dunno, sorry, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm/i915: new warning (regression) in 3.7.10 and 3.8.3
On Mon, Mar 18, 2013 at 09:32:51AM +0100, Daniel Vetter wrote: > > Another pesky BIOS which changes the display state behind our back on lid > closing! Should be duct-tapped over with > > commit 45e2b5f640b3766da3eda48f6c35f088155c06f3 > Author: Daniel Vetter > Date: Fri Nov 23 18:16:34 2012 +0100 > > drm/i915: force restore on lid open > > which is in 3.8. But that warning was from a 3.8.3 kernel. Any other ideas? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmc: rts_pstor worked fine, but rtsx_pci_sdmmc does not
On Mon, Mar 18, 2013 at 09:58:46AM +0800, wwang wrote: > Hi Richard: > > Could you please describe the detailed model of your 4G card? It > would be better if you can take a picture of that card or give me > the Amazon link of it. It looks like a compatibility issue. The lettering on the card is: micro SD HC 4 GB C04G TAIWAN (serial number) Kingston SDC4/4GB 086 FC s On Amazon they have a similar device, but the lettering looks a bit different. The one I have look like this. http://img01.taobaocdn.com/bao/uploaded/i1/T1.7SyXXlBXXbq.6I8_071230.jpg Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/5] kconfig: implement weak reverse-dependencies
On Thu, Mar 21, 2013 at 12:22:57PM +0400, Konstantin Khlebnikov wrote: > This patch adds new kind of dependencies between kconfig symbols, > and new kconfig keyword 'apply' for them. > > 'apply' works mostly like 'select', but it allows to disable target symbol. > Thus target symbol will be either disabled or reachable from current symbol. > > This method allows to implement optional dependencies without introducing new > kconfig symbol for each pair of connected kconfig options. I don't really understand what the point of this new keyword is, but I wonder why you chose PTP Hardware Clocks as your Guinea pig. As discussed on the netdev list [1][2], the consensus was that if a MAC driver has a PHC, then it should always be compiled in. And BTW, please CC netdev for PHC patches. Thanks, Richard 1. http://marc.info/?l=linux-netdev&m=135173341101960 2. http://www.spinics.net/lists/netdev/msg215379.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/5] kconfig: implement weak reverse-dependencies
On Thu, Mar 21, 2013 at 03:06:11PM +0400, Konstantin Khlebnikov wrote: > > As I see this technology requires special dedicated server in the local > network, thus it's unusable in most situations. But it starts working > without any actions from the user (please fix me if I'm wrong). Perhaps you don't have a very clear picture of how this PTP stuff works. Even when the PHC and time stamping code is compiled in, it does *not* start working unless the end user turns it on, via the SIOCSHWTSTAMP and SO_TIMESTAMPING options. See: Documentation/networking/timestamping.txt Documentation/ptp/ptp.txt > Thus this code enables some rarely used parts of hardware. > After seeing several weird bugs in ethernet devices I prefer to > keep unused/unwanted features off. Just compiling drivers into kernel does not really change the behavior of the hardware. The only drawback I know of is that it adds (minimal) overhead into the packet processing paths, but that is a software issue. I don't mean to start a big discussion here. The question of whether to have PHC support a compile time option should be discussed on the netdev list (added on CC just in case). Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples
On Wed, Apr 03, 2013 at 10:50:57AM -0700, John Stultz wrote: > > I get the reasoning around reusing the fd we already have, but is > the possibility of a dynamic chardev pathname really a big concern? I have been following this thread, and, not knowing very much about perf, I would think that the userland can easily open a second file (the dynamic posix clock chardev) in order to get these time stamps. > Maybe can we extend the dynamic posix clock code to work on more > then just the chardev? Although I worry about multiplexing too much > functionality on the file. I don't yet see a need for that, but if we do, then it should work in a generic way, and not as a list of special cases, like we saw in the patch. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/4] Add support for LZ4-compressed kernels
On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote: > > It's a lot of code for a 50ms boot-time improvement. Does anyone have > any opinions on whether or not the benefits are worth the cost? In the embedded space, quick boot is a really important feature to have. Many people resort to awful hacks in order to improve boot time, and so I would welcome this option. I have seen arm systems that boot in 300 ms. I would say that 50 ms is maybe not such a small improvement after all. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptp: PTP_1588_CLOCK_PCH depends on x86
On Wed, Jan 30, 2013 at 12:31:01PM -0500, Jeff Mahoney wrote: > The EG20T PCH is only compatible with Intel Atom processors so it > should depend on x86. Yes, there is something wrong with PTP_1588_CLOCK_PCH. The last several times I did 'make oldconfig' for various configs, it asked me whether to enable this 'new' option. That is really annoying, especially with non-atom and non-x86 builds. Ben, you removed the PCH_GBE dependency in 18d359ce. Are you sure that was the right thing to do? Thanks, Richard > Cc: Richard Cochran > Signed-off-by: Jeff Mahoney > --- > drivers/ptp/Kconfig |1 + > 1 file changed, 1 insertion(+) > > --- a/drivers/ptp/Kconfig > +++ b/drivers/ptp/Kconfig > @@ -72,6 +72,7 @@ config DP83640_PHY > > config PTP_1588_CLOCK_PCH > tristate "Intel PCH EG20T as PTP clock" > + depends on X86 > select PTP_1588_CLOCK > help > This driver adds support for using the PCH EG20T as a PTP > > -- > Jeff Mahoney > SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpsw: Fix interrupt storm among other things
On Mon, Jan 28, 2013 at 03:11:08PM +0200, Pantelis Antoniou wrote:
> Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling.
> While at it, added a non-NAPI mode (which is easier to debug), plus
> some general fixes.
I have a few issues with this patch:
1. This is a networking patch. It should be addressed to netdev, it it
needs to have davem on CC.
2. The description is poor. You need to tell us more about this
"storm". How can one trigger it? What is the effect? Does the
system lock up, or is the throughput poor? Tell us exactly what the
problem is. Tell us what is wrong in the interrupt handling, and
how the patch improves the situation.
3. Don't just say "general fixes", but do say exactly what you fixed.
4. Adding non-NAPI code is going backwards. Don't do that (and see the
recent discussion on netdev on just this very topic: Frank Li and
the fec driver).
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 40aff68..b6ca4af 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -148,10 +148,37 @@ struct cpsw_wr_regs {
> u32 soft_reset;
> u32 control;
> u32 int_control;
> - u32 rx_thresh_en;
> - u32 rx_en;
> - u32 tx_en;
> - u32 misc_en;
> + u32 c0_rx_thresh_en;
> + u32 c0_rx_en;
> + u32 c0_tx_en;
> + u32 c0_misc_en;
How does renaming these help?
(If you really think that new names are needed, then put the cosmetic
renaming changes into its a separate patch.)
> + u32 c1_rx_thresh_en;
> + u32 c1_rx_en;
> + u32 c1_tx_en;
> + u32 c1_misc_en;
You added a bunch of new fields, but you don't use any of them.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpsw: Fix interrupt storm among other things
On Mon, Jan 28, 2013 at 03:11:08PM +0200, Pantelis Antoniou wrote: > Fix interrupt storm on bone A4 cause by non-by-the-book interrupt handling. > While at it, added a non-NAPI mode (which is easier to debug), plus > some general fixes. This patch does not apply to net-next. When you do post to netdev, please also put "net" or "net-next" into the subject line. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpsw: Fix interrupt storm among other things
On Mon, Jan 28, 2013 at 08:40:25PM +0200, Pantelis Antoniou wrote: > Hi Richard, > > Yes, I guess this was more of a drive-by patch dump - but people need this > to get PG2.0 silicon to work on am33xx. And what is PG2.0? > And no, I don't think having a non-NAPI code path is backwards, especially > when trying to debug hardware problems; the non-NAPI driver is much easier > to understand and follow, especially when there is a convoluted method > you have to follow to have the h/w acknowledge the interrupt. Special debug modes are fine to have, but not in mainline code. I suggest taking a look at the recent netdev discussion on this. Someone wanted to make napi/non-napi a DT option, and it got nixed. > Not every device can be conveniently be made to shut up so that NAPI > processing > can take place at a later time. So, are you saying that the cpsw cannot work as a napi device? > The NAPI case is still broken in this driver, which OOPs under load. And does your patch fix it, or not? It would be nice to know what the problem is, and how to reproduce it. I haven't seen any OOPs on the beaglebone, but maybe I am not trying hard enough. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cpsw: Fix interrupt storm among other things
On Mon, Jan 28, 2013 at 08:40:25PM +0200, Pantelis Antoniou wrote: > > Speaking of which, I'm probably the original developer of the fec driver. BTW, as I mentioned, someone is converting fec to napi. Care to take a look to make sure it is done right? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
drm/i915: new warning (regression) in 3.7.10 and 3.8.3
I have an Acer Aspire One netbook, and on it I get the following warning when closing and opening the lid. I think this warning first appeared in 3.7. Does this need fixing? If so, who can do it? Thanks, Richard ** close lid Mar 16 11:32:03 netboy kernel: [ 287.429404] [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode! Mar 16 11:32:03 netboy kernel: [ 287.429440] [ cut here ] Mar 16 11:32:03 netboy kernel: [ 287.429526] WARNING: at /home/richard/git/linux/drivers/gpu/drm/i915/intel_display.c:7877 intel_modeset_check_state+0x2f8/0x452 [i915]() Mar 16 11:32:03 netboy kernel: [ 287.429537] Hardware name: AOD257 Mar 16 11:32:03 netboy kernel: [ 287.429548] encoder's hw state doesn't match sw tracking (expected 1, found 0) Mar 16 11:32:03 netboy kernel: [ 287.429556] Modules linked in: mmc_block bluetooth crc16 cpufreq_stats cpufreq_userspace cpufreq_powersave cpufreq_conservative uinput fuse loop snd_hda_codec_realtek joydev arc4 iwldvm snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm mac80211 i915 snd_timer snd iwlwifi cfg80211 tpm_tis psmouse serio_raw drm_kms_helper tpm i2c_i801 soundcore evdev hid_generic drm i2c_algo_bit video pcspkr tpm_bios i2c_core ehci_pci snd_page_alloc acpi_cpufreq mperf battery ac rfkill wmi processor button ext3 jbd mbcache sd_mod crc_t10dif usbhid hid rtsx_pci_sdmmc mmc_core ahci libahci libata scsi_mod uhci_hcd ehci_hcd usbcore usb_common thermal thermal_sys rtsx_pci mfd_core r8169 mii Mar 16 11:32:03 netboy kernel: [ 287.429771] Pid: 34, comm: kworker/0:1 Not tainted 3.8.3 #74 Mar 16 11:32:03 netboy kernel: [ 287.429781] Call Trace: Mar 16 11:32:03 netboy kernel: [ 287.429808] [] ? warn_slowpath_common+0x6a/0x7b Mar 16 11:32:03 netboy kernel: [ 287.429882] [] ? intel_modeset_check_state+0x2f8/0x452 [i915] Mar 16 11:32:03 netboy kernel: [ 287.429904] [] ? warn_slowpath_fmt+0x28/0x2c Mar 16 11:32:03 netboy kernel: [ 287.429975] [] ? intel_modeset_check_state+0x2f8/0x452 [i915] Mar 16 11:32:03 netboy kernel: [ 287.430017] [] ? intel_set_mode+0x61a/0x6aa [i915] Mar 16 11:32:03 netboy kernel: [ 287.430162] [] ? intel_set_mode+0x654/0x6aa [i915] Mar 16 11:32:03 netboy kernel: [ 287.430290] [] ? intel_modeset_setup_hw_state+0x5e0/0x70a [i915] Mar 16 11:32:03 netboy kernel: [ 287.430386] [] ? intel_lid_notify+0x7a/0x8a [i915] Mar 16 11:32:03 netboy kernel: [ 287.430409] [] ? notifier_call_chain+0x23/0x46 Mar 16 11:32:03 netboy kernel: [ 287.430449] [] ? __blocking_notifier_call_chain+0x39/0x4c Mar 16 11:32:03 netboy kernel: [ 287.430470] [] ? blocking_notifier_call_chain+0x9/0xc Mar 16 11:32:03 netboy kernel: [ 287.430500] [] ? acpi_lid_send_state+0x7d/0xa0 [button] Mar 16 11:32:03 netboy kernel: [ 287.430532] [] ? acpi_button_notify+0x2b/0x95 [button] Mar 16 11:32:03 netboy kernel: [ 287.430557] [] ? acpi_device_notify+0xf/0x11 Mar 16 11:32:03 netboy kernel: [ 287.430578] [] ? acpi_ev_notify_dispatch+0x2b/0x42 Mar 16 11:32:03 netboy kernel: [ 287.430597] [] ? acpi_os_execute_deferred+0x18/0x21 Mar 16 11:32:03 netboy kernel: [ 287.430617] [] ? process_one_work+0x1b1/0x27e Mar 16 11:32:03 netboy kernel: [ 287.430637] [] ? worker_thread+0x115/0x203 Mar 16 11:32:03 netboy kernel: [ 287.430656] [] ? process_one_work+0x27e/0x27e Mar 16 11:32:03 netboy kernel: [ 287.430672] [] ? kthread+0x8d/0x92 Mar 16 11:32:03 netboy kernel: [ 287.430691] [] ? ret_from_kernel_thread+0x1b/0x28 Mar 16 11:32:03 netboy kernel: [ 287.430707] [] ? kthread_freezable_should_stop+0x4b/0x4b Mar 16 11:32:03 netboy kernel: [ 287.430720] ---[ end trace 4a7da2dcc2431943 ]--- ** open lid Mar 16 11:32:03 netboy kernel: [ 287.430746] [ cut here ] Mar 16 11:32:03 netboy kernel: [ 287.430849] WARNING: at /home/richard/git/linux/drivers/gpu/drm/i915/intel_display.c:7911 intel_modeset_check_state+0x3f3/0x452 [i915]() Mar 16 11:32:03 netboy kernel: [ 287.430889] Hardware name: AOD257 Mar 16 11:32:03 netboy kernel: [ 287.430928] crtc's computed active state doesn't match tracked active state (expected 1, found 0) Mar 16 11:32:03 netboy kernel: [ 287.430964] Modules linked in: mmc_block bluetooth crc16 cpufreq_stats cpufreq_userspace cpufreq_powersave cpufreq_conservative uinput fuse loop snd_hda_codec_realtek joydev arc4 iwldvm snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm mac80211 i915 snd_timer snd iwlwifi cfg80211 tpm_tis psmouse serio_raw drm_kms_helper tpm i2c_i801 soundcore evdev hid_generic drm i2c_algo_bit video pcspkr tpm_bios i2c_core ehci_pci snd_page_alloc acpi_cpufreq mperf battery ac rfkill wmi processor button ext3 jbd mbcache sd_mod crc_t10dif usbhid hid rtsx_pci_sdmmc mmc_core ahci libahci libata scsi_mod uhci_hcd ehci_hcd usbcore usb_common thermal thermal_sys rtsx_pci mfd_core r8169 mii Mar 16 11:32:03 netboy kernel: [ 287.431233] Pid: 34, comm: kworker/0:1 Tainted: GW3
mmc: rts_pstor worked fine, but rtsx_pci_sdmmc does not
I have an Acer Aspire One netbook with a built in card reader, and I have two cards, one with 32 MB and one with 4 GB. The card reader used to work with the staging driver in 3.7.10, but the new 3.8.3 driver does not work with the larger card. The old driver was removed in commit cd211222. Now, when inserting the larger card, the kernel just prints an error, as shown below. Anyone know how to fix this? Thanks, Richard ** With new 3.8.3 driver *** 32 MB card Mar 16 11:29:45 netboy kernel: [ 149.431780] mmc0: new MMC card at address 0001 Mar 16 11:29:45 netboy kernel: [ 149.519891] mmcblk0: mmc0:0001 32M30.6 MiB Mar 16 11:29:45 netboy kernel: [ 149.524102] mmcblk0: p1 Mar 16 11:30:20 netboy kernel: [ 184.195164] mmc0: card 0001 removed *** 4G MB card Mar 16 11:31:13 netboy kernel: [ 237.267134] mmc0: error -110 whilst initialising SD card Mar 16 11:31:14 netboy kernel: [ 238.497137] mmc0: error -110 whilst initialising SD card Mar 16 11:31:15 netboy kernel: [ 239.727136] mmc0: error -110 whilst initialising SD card ** With old 3.7.10 staging driver *** 32 MB card Mar 16 13:11:01 netboy kernel: [ 129.222352] sd 4:0:0:0: [sdb] 62720 512-byte logical blocks: (32.1 MB/30.6 MiB) Mar 16 13:11:01 netboy kernel: [ 129.222559] sd 4:0:0:0: [sdb] Cache data unavailable Mar 16 13:11:01 netboy kernel: [ 129.222572] sd 4:0:0:0: [sdb] Assuming drive cache: write through Mar 16 13:11:01 netboy kernel: [ 129.222985] sd 4:0:0:0: [sdb] Cache data unavailable Mar 16 13:11:01 netboy kernel: [ 129.223002] sd 4:0:0:0: [sdb] Assuming drive cache: write through Mar 16 13:11:01 netboy kernel: [ 129.226132] sdb: sdb1 Mar 16 13:11:09 netboy kernel: [ 136.909833] sdb: detected capacity change from 32112640 to 0 *** 4 GB card Mar 16 13:12:45 netboy kernel: [ 232.909525] sd 4:0:0:0: [sdb] 7626752 512-byte logical blocks: (3.90 GB/3.63 GiB) Mar 16 13:12:45 netboy kernel: [ 232.909769] sd 4:0:0:0: [sdb] Cache data unavailable Mar 16 13:12:45 netboy kernel: [ 232.909786] sd 4:0:0:0: [sdb] Assuming drive cache: write through Mar 16 13:12:45 netboy kernel: [ 232.910593] sd 4:0:0:0: [sdb] Cache data unavailable Mar 16 13:12:45 netboy kernel: [ 232.910612] sd 4:0:0:0: [sdb] Assuming drive cache: write through Mar 16 13:12:45 netboy kernel: [ 232.912631] sdb: sdb1 sdb2 Mar 16 13:12:59 netboy kernel: [ 246.909480] sdb: detected capacity change from 3904897024 to 0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 116/193] drivers/ptp: remove CONFIG_EXPERIMENTAL
On Tue, Oct 23, 2012 at 01:03:09PM -0700, Kees Cook wrote: > This config item has not carried much meaning for a while now and is > almost always enabled by default. As agreed during the Linux kernel > summit, remove it. > > CC: Richard Cochran > Signed-off-by: Kees Cook Acked-by: Richard Cochran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] lxt PHY: Support for the buggy LXT973 rev A2
On Sat, Sep 22, 2012 at 06:16:49PM +0200, Christophe Leroy wrote:
> This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
> precautions linked to ERRATA Item 4:
>
> Revision A2 of LXT973 chip randomly returns the contents of the previous even
> register when you read a odd register regularly
This patch does not apply to net-next.
Also, I have just a few stylistic comments, below.
> Signed-off-by: Christophe Leroy
>
> diff -u linux-3.5-vanilla/drivers/net/phy/lxt.c
> linux-3.5/drivers/net/phy/lxt.c
> --- linux-3.5-vanilla/drivers/net/phy/lxt.c 2012-07-21 22:58:29.0
> +0200
> +++ linux-3.5/drivers/net/phy/lxt.c 2012-09-15 19:20:34.0 +0200
...
> +int lxt973a2_read_status(struct phy_device *phydev)
> +{
> + int adv;
> + int err;
> + int lpa;
> + int lpagb = 0;
> +
> + /* Update the link, but return if there was an error */
> + err = lxt973a2_update_link(phydev);
> + if (err)
> + return err;
> +
> + if (AUTONEG_ENABLE == phydev->autoneg) {
> + int retry = 1;
> +
> + adv = phy_read(phydev, MII_ADVERTISE);
> +
> + if (adv < 0)
> + return adv;
> +
> + do {
> + lpa = phy_read(phydev, MII_LPA);
> +
> + if (lpa < 0)
> + return lpa;
> +
> + /* If both registers are equal, it is suspect but not
> + * impossible, hence a new try
> + */
> + } while (lpa == adv && retry--);
> +
> + lpa &= adv;
> +
> + phydev->speed = SPEED_10;
> + phydev->duplex = DUPLEX_HALF;
> + phydev->pause = phydev->asym_pause = 0;
> +
> + if (lpagb & (LPA_1000FULL | LPA_1000HALF)) {
> + phydev->speed = SPEED_1000;
> +
> + if (lpagb & LPA_1000FULL)
> + phydev->duplex = DUPLEX_FULL;
> + } else if (lpa & (LPA_100FULL | LPA_100HALF)) {
> + phydev->speed = SPEED_100;
> +
> + if (lpa & LPA_100FULL)
> + phydev->duplex = DUPLEX_FULL;
> + } else
> + if (lpa & LPA_10FULL)
> + phydev->duplex = DUPLEX_FULL;
This last 'else' could use braces.
> +
> + if (phydev->duplex == DUPLEX_FULL) {
> + phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
> + phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
> + }
> + } else {
> + int bmcr = phy_read(phydev, MII_BMCR);
> +
> + if (bmcr < 0)
> + return bmcr;
> +
> + if (bmcr & BMCR_FULLDPLX)
> + phydev->duplex = DUPLEX_FULL;
> + else
> + phydev->duplex = DUPLEX_HALF;
> +
> + if (bmcr & BMCR_SPEED1000)
> + phydev->speed = SPEED_1000;
> + else if (bmcr & BMCR_SPEED100)
> + phydev->speed = SPEED_100;
> + else
> + phydev->speed = SPEED_10;
> +
> + phydev->pause = phydev->asym_pause = 0;
> + }
> +
> + return 0;
> +}
> +
> +static int lxt973_read_status(struct phy_device *phydev)
> +{
> + return (int)phydev->priv&PHYDEV_PRIV_REVA2 ?
> + lxt973a2_read_status(phydev) :
> + genphy_read_status(phydev);
Needs spacing, like this:
return (int) phydev->priv & PHYDEV_PRIV_REVA2 ?
lxt973a2_read_status(phydev) : genphy_read_status(phydev);
> +}
> +
> static int lxt973_probe(struct phy_device *phydev)
> {
> int val = phy_read(phydev, MII_LXT973_PCR);
> + int priv = 0;
> +
> + phydev->priv = NULL;
> +
> + if (val < 0)
> + return val;
>
> if (val & PCR_FIBER_SELECT) {
> /*
> @@ -136,17 +272,26 @@
> val &= ~BMCR_ANENABLE;
> phy_write(phydev, MII_BMCR, val);
> /* Remember that the port is in fiber mode. */
> - phydev->priv = lxt973_probe;
> - } else {
> - phydev->priv = NULL;
> + priv |= PHYDEV_PRIV_FIBER;
> + }
> + val = phy_read(phydev, MII_PHYSID2);
> +
> + if (val < 0)
> + return val;
> +
> + if ((val & 0xf) == 0) { /* rev A2 */
> + dev_info(&phydev->dev, " LXT973 revision A2 has bugs\n");
> + priv |= PHYDEV_PRIV_REVA2;
> }
> + phydev->priv = (void *)priv;
One space after cast, please: (void *) priv;
> return 0;
> }
>
> static int lxt973_config_aneg(struct phy_device *phydev)
> {
> /* Do nothing if port is in fiber mode. */
> - return phydev->priv ? 0 : genphy_config_aneg(phydev);
> + return (int)phydev->priv&PHYDEV_PRIV_FIBER ?
> + 0 : genphy_config_aneg(phydev);
Same spacing issue agai
Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
On Mon, Sep 24, 2012 at 04:00:58PM +0200, Christophe Leroy wrote:
> diff -u a/drivers/net/phy/lxt.c b/drivers/net/phy/lxt.c
> --- a/drivers/net/phy/lxt.c 2012-09-23 03:08:48.0 +0200
> +++ b/drivers/net/phy/lxt.c 2012-09-23 03:18:00.0 +0200
...
> @@ -175,6 +292,16 @@
> .driver = { .owner = THIS_MODULE,},
> }, {
> .phy_id = 0x00137a10,
> + .name = "LXT973-A2",
> + .phy_id_mask= 0x,
> + .features = PHY_BASIC_FEATURES,
> + .flags = 0,
> + .probe = lxt973_probe,
> + .config_aneg= lxt973_config_aneg,
> + .read_status= lxt973a2_read_status,
I like this way of matching the A2 chips much better than what you had
before. But are you sure this will work correctly?
What do A3 chips have in the last nibble of phy_id?
> + .driver = { .owner = THIS_MODULE,},
> +}, {
> + .phy_id = 0x00137a10,
> .name = "LXT973",
> .phy_id_mask= 0xfff0,
> .features = PHY_BASIC_FEATURES,
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lxt PHY: Support for the buggy LXT973 rev A2
On Tue, Sep 25, 2012 at 08:23:42AM +0200, leroy christophe wrote: > > A2 chip has phy_id 0x00137a10 > A3 chip has phy_id 0x00137a11 Okay then, thanks. Acked-by: Richard Cochran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PULL REQ] IXP4xx changes for Linux 3.7
On Thu, Oct 18, 2012 at 12:01:17AM +0200, Krzysztof Halasa wrote: > > Don't get me wrong. If I had time for this it could be different. > Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at > this point. Given the raised barriers to participate, probably aimed at > paid maintainers, I have to quit doing this. > > BTW since Imre has probably even much less time, it would be a good time > to find someone to maintain IXP4xx code. I will be publishing (from time > to time) my tree (I'm using the hw myself), so even simple > cherry-picking would probably make some sense. So if no one else wants to do this, then I am willing to look after the IXP code. I think that I do have the time for it. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is it desirable to improve the build system?
On Thu, Jul 11, 2013 at 02:22:14PM -0700, Mark Galeck wrote: > >The answer to "is it desirable to improve X?" is always "yes." But > > the only way to make progress in Linux is to actually post patches > that "improve X." This is unlike many corporate environments, where > you might need to get somebody's approval > > > Precisely. Please excuse me coming from a corporate background. > In corporate, even if you "get somebody's approval", there may be "other > stakeholders" who may "feel ownership" etc etc Yes, your approved project may get canned later. But the point was, that you aren't allowed to even get started without someone's approval. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptp: measure the time offset between PHC and system clock
On Sat, Sep 14, 2013 at 04:03:06PM +0800, Dong Zhu wrote:
> This patch add a method into testptp.c to measure the time offset
> between phc and system clock through the ioctl PTP_SYS_OFFSET.
>
This is a nice addition to the testptp program. I do have a few
comments, below.
First off, the subject line should mention testptp. How about this?
[PATCH] ptp: add the PTP_SYS_OFFSET ioctl to the testptp program
> Signed-off-by: Dong Zhu
> ---
> Documentation/ptp/testptp.c | 40 ++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
> index f59ded0..72bb030 100644
> --- a/Documentation/ptp/testptp.c
> +++ b/Documentation/ptp/testptp.c
> @@ -112,6 +112,7 @@ static void usage(char *progname)
> " -f val adjust the ptp clock frequency by 'val' ppb\n"
> " -g get the ptp clock time\n"
> " -h prints this message\n"
> + " -k val measure the time offset between PHC and system
> clock\n"
The help message should tell the user what 'val' is.
> " -p val enable output with a period of 'val' nanoseconds\n"
> " -P val enable or disable (val=1|0) the system clock PPS\n"
> " -s set the ptp clock time from the system time\n"
> @@ -133,8 +134,12 @@ int main(int argc, char *argv[])
> struct itimerspec timeout;
> struct sigevent sigevent;
>
> + struct ptp_clock_time *pct;
> + struct ptp_sys_offset *sysoff;
> +
> +
> char *progname;
> - int c, cnt, fd;
> + int i, c, cnt, fd;
>
> char *device = DEVICE;
> clockid_t clkid;
> @@ -144,6 +149,8 @@ int main(int argc, char *argv[])
> int extts = 0;
> int gettime = 0;
> int oneshot = 0;
> + int offset = 0;
> + int n_samples = 0;
> int periodic = 0;
> int perout = -1;
> int pps = -1;
> @@ -151,7 +158,7 @@ int main(int argc, char *argv[])
>
> progname = strrchr(argv[0], '/');
> progname = progname ? 1+progname : argv[0];
> - while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) {
> + while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghk:p:P:sSt:v"))) {
> switch (c) {
> case 'a':
> oneshot = atoi(optarg);
> @@ -174,6 +181,10 @@ int main(int argc, char *argv[])
> case 'g':
> gettime = 1;
> break;
> + case 'k':
> + offset = 1;
> + n_samples = atoi(optarg);
> + break;
> case 'p':
> perout = atoi(optarg);
> break;
> @@ -376,6 +387,31 @@ int main(int argc, char *argv[])
> }
> }
>
> + if (offset) {
> + sysoff = calloc(1, sizeof(*sysoff));
> + if (!sysoff) {
> + perror("calloc");
> + return -1;
> + }
> + sysoff->n_samples = n_samples;
> +
> + if (ioctl(fd, PTP_SYS_OFFSET, sysoff))
> + perror("PTP_SYS_OFFSET");
> + else
> + puts("time offset between PHC and
> + system clock request okay");
> +
> + pct = &sysoff->ts[0];
> + for (i = 0; i < sysoff->n_samples; i++, pct++) {
> + printf("system time: %ld.%ld\n", pct->sec, pct->nsec);
> + pct++;
> + printf("phctime: %ld.%ld\n\n", pct->sec, pct->nsec);
I think the output would look nicer with only one newline. After all,
each measurement is a {sys,phc,sys} triplet and not a {sys,phc} pair.
> + }
> + printf("system time: %ld.%ld\n", pct->sec, pct->nsec);
> +
> + free(sysoff);
> + }
> +
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptp: add the PTP_SYS_OFFSET ioctl to the testptp program clock
On Sat, Sep 14, 2013 at 11:39:52PM +0800, Dong Zhu wrote: > On Sat, Sep 14, 2013 at 04:31:46PM +0200, Richard Cochran wrote: > > On Sat, Sep 14, 2013 at 04:03:06PM +0800, Dong Zhu wrote: > > > This patch add a method into testptp.c to measure the time offset > > > between phc and system clock through the ioctl PTP_SYS_OFFSET. > > > > > > > This is a nice addition to the testptp program. I do have a few > > comments, below. > > > > Thanks very much for your comments, I have modified the patch as below, > Cuold you have a look at it again ? Any comments would be appreciated. It looks better, but could you please tweak a few more things? > Subject: Re: [PATCH] ptp: add the PTP_SYS_OFFSET ioctl to the testptp program > clock The subject line has the word "clock" at the end by mistake. ... > diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c > index f59ded0..8acdc70 100644 > --- a/Documentation/ptp/testptp.c > +++ b/Documentation/ptp/testptp.c > @@ -112,6 +112,8 @@ static void usage(char *progname) > " -f val adjust the ptp clock frequency by 'val' ppb\n" > " -g get the ptp clock time\n" > " -h prints this message\n" > + " -k val measure the time offset between phc and system > clock " > + "for 'val' times (Maximum 25)\n" This line is getting a bit too long for the terminal. Please line up the text, like this: " -k val measure the time offset between phc and system clock\n" "for 'val' times (Maximum 25)\n" Also, when you resubmit the patch, add "net-next" and a patch version, like this: [PATCH net-next v3]. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 2/2] tuntap: orphan frags before trying to set tx timestamp
On Wed, Sep 04, 2013 at 12:33:46PM +0800, Jason Wang wrote: > sock_tx_timestamp() will clear all zerocopy flags of skb which may lead the > frags never to be orphaned. This will break guest to guest traffic when > zerocopy > is enabled. Fix this by orphaning the frags before trying to set tx time > stamp. > > The issue were introduced by commit eda297729171fe16bf34fe5b0419dfb69060f623 > (tun: Support software transmit time stamping). > > Cc: Richard Cochran > Signed-off-by: Jason Wang Acked-by: Richard Cochran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 1/2] tuntap: purge socket error queue on detach
On Wed, Sep 04, 2013 at 12:33:45PM +0800, Jason Wang wrote: > Commit eda297729171fe16bf34fe5b0419dfb69060f623 > (tun: Support software transmit time stamping) will queue skbs into error > queue > when tx stamping is enabled. But it forgets to purge the error queue during > detach. This patch fixes this. > > Cc: Richard Cochran > Signed-off-by: Jason Wang Acked-by: Richard Cochran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clock_gettime_ns
On Mon, Sep 09, 2013 at 10:47:01AM -0700, Andy Lutomirski wrote: > > I think that coming up with something that's both non-POSIX and > half-arsed is a bad idea, but doing something that's non-POSIX and > well thought-through could be valuable. I know Harlan Stenn of the Network Time Foundation is working on a new timestamp API and presented a paper at the conference: Requirements for UTC and Civil Timekeeping on Earth A Colloquium Addressing a Continuous Time Standard University of Virginia, Charlottesville, May 29-31, 2013. http://www.cacr.caltech.edu/futureofutc/ The slides are on that site, and I would bet that the paper could be made available. In any case, since I think any kind of new time API idea would benefit from review and acceptance from the NTP and BSD people. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptp: add range check on n_samples
On Tue, Sep 24, 2013 at 03:05:57PM +0800, Dong Zhu wrote:
> From d4eb97e8d5def76d46167c91059147e2c7d33433 Mon Sep 17 00:00:00 2001
>
> When using PTP_SYS_OFFSET ioctl to measure the time offset between the
> PHC and system clock, we need to specify the number of measurements, the
> valid value of n_samples is between 1 to 25. If n_samples <= 0 or > 25
> it makes no sense, so this patch intends to add a range check.
The field, n_samples, is unsigned, so the check is not needed.
Thanks,
Richard
> Signed-off-by: Dong Zhu
> ---
> drivers/ptp/ptp_chardev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
> index 34a0c60..4e85b23 100644
> --- a/drivers/ptp/ptp_chardev.c
> +++ b/drivers/ptp/ptp_chardev.c
> @@ -104,7 +104,8 @@ long ptp_ioctl(struct posix_clock *pc, unsigned int cmd,
> unsigned long arg)
> err = -EFAULT;
> break;
> }
> - if (sysoff->n_samples > PTP_MAX_SAMPLES) {
> + if (sysoff->n_samples <= 0 ||
> + sysoff->n_samples > PTP_MAX_SAMPLES) {
> err = -EINVAL;
> break;
> }
> --
> 1.7.11.7
>
> --
> Best Regards,
> Dong Zhu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] lxt PHY: Support for the buggy LXT973 rev A2
On Mon, Sep 10, 2012 at 05:45:49PM +0200, Christophe Leroy wrote:
> This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
> precautions linked to ERRATA Item 4:
I have a few nit picking remarks, below...
> Item 4: MDIO Interface and Repeated Polling
> Problem: Repeated polling of odd-numbered registers via the MDIO interface
> randomly returns the contents of the previous even register.
> Implication: Managed applications may not obtain the correct register contents
> when a particular register is monitored for device status.
> Workaround: None.
> Status: This erratum has been previously fixed (in rev A3)
This text looks like it has been copied verbatim from a errata
sheet. If so, that document is probably under someone else's
copyright. If am right, then you should paraphrase the erratum
instead, both here and in the code comment.
>
> Signed-off-by: Christophe Leroy
>
> diff -u linux-3.5-vanilla/drivers/net/phy/lxt.c
> linux-3.5/drivers/net/phy/lxt.c
> --- linux-3.5-vanilla/drivers/net/phy/lxt.c 2012-07-21 22:58:29.0
> +0200
> +++ linux-3.5/drivers/net/phy/lxt.c 2012-09-07 18:08:54.0 +0200
> @@ -7,6 +7,10 @@
> *
> * Copyright (c) 2004 Freescale Semiconductor, Inc.
> *
> + * Copyright (c) 2010 CSSI
> + *
> + * Added support for buggy LXT973 rev A2
We don't do change logs in the code. That is what git is for.
Also, I think it is a bit of a stretch to add your copyright here.
> + *
> * This program is free software; you can redistribute it and/or modify it
> * under the terms of the GNU General Public License as published by the
> * Free Software Foundation; either version 2 of the License, or (at your
> @@ -54,8 +58,12 @@
> #define MII_LXT971_ISR 19 /* Interrupt Status Register */
>
> /* register definitions for the 973 */
> -#define MII_LXT973_PCR 16 /* Port Configuration Register */
> +#define MII_LXT973_PCR 16 /* Port Configuration Register */
> #define PCR_FIBER_SELECT 1
> +#define MII_LXT973_SFR 27 /* Special Function Register */
> +
> +#define PHYDEV_PRIV_FIBER1
> +#define PHYDEV_PRIV_REVA22
>
> MODULE_DESCRIPTION("Intel LXT PHY driver");
> MODULE_AUTHOR("Andy Fleming");
> @@ -99,6 +107,9 @@
> return err;
> }
>
> +/* register definitions for the 973 */
> +#define MII_LXT973_PCR 16 /* Port Configuration Register */
> +#define PCR_FIBER_SELECT 1
>
> static int lxt971_ack_interrupt(struct phy_device *phydev)
> {
> @@ -122,9 +133,141 @@
> return err;
> }
>
> +/*
> + * ERRATA on LXT973
> + *
> + * Item 4: MDIO Interface and Repeated Polling
> + * Problem: Repeated polling of odd-numbered registers via the MDIO
> interface randomly returns the
> + * contents of the previous even register.
> + * Implication: Managed applications may not obtain the correct register
> contents when a particular
> + * register is monitored for device status.
> + * Workaround: None.
> + * Status: This erratum has been previously fixed (in rev A3)
> + *
> + */
Please make sure that the above text is your own words.
> +static int lxt973a2_update_link(struct phy_device *phydev)
> +{
> + int status;
> + int control;
> + int retry = 8; /* we try 8 times */
> +
> + /* Do a fake read */
> + status = phy_read(phydev, MII_BMSR);
> +
> + if (status < 0)
> + return status;
> +
> + control = phy_read(phydev, MII_BMCR);
> + if (control < 0)
> + return control;
> +
> + do {
> + /* Read link and autonegotiation status */
> + status = phy_read(phydev, MII_BMSR);
> + } while (status>=0 && retry-- && status == control);
spacing: status >= 0
> +
> + if (status < 0)
> + return status;
> +
> + if ((status & BMSR_LSTATUS) == 0)
> + phydev->link = 0;
> + else
> + phydev->link = 1;
> +
> + return 0;
> +}
> +
> +int lxt973a2_read_status(struct phy_device *phydev)
> +{
> + int adv;
> + int err;
> + int lpa;
> + int lpagb = 0;
> +
> + /* Update the link, but return if there was an error */
> + err = lxt973a2_update_link(phydev);
> + if (err)
> + return err;
> +
> + if (AUTONEG_ENABLE == phydev->autoneg) {
> + int retry = 1;
> +
> + adv = phy_read(phydev, MII_ADVERTISE);
> +
> + if (adv < 0)
> + return adv;
> +
> + do {
> + lpa = phy_read(phydev, MII_LPA);
> +
> + if (lpa < 0)
> + return lpa;
> +
> + /* If both registers are equal, it is suspect but not
> impossible, hence a new try */
Trailing white space. Line is way too long.
> + } while (lpa == adv && retry--);
> +
> + lpa &= adv;
> +
> + phydev->speed = SPEED_10;
> + phydev->duplex = DUPLEX_HALF;
> + phydev->pa
Re: [net:master 1/9] pch_gbe_main.c:(.text+0x510370): undefined reference to `pch_ch_control_write'
On Sat, Oct 06, 2012 at 10:07:23PM +0800, Haicheng Li wrote: > > IMHO, the reason why the dependency of PCH_PTP becomes so tricky is > that the code of these two modules call the functions of each other > (bad code structure?). Yes, that is the source of the problem. I don't recall how this habit of having the PTP option as a module got started (and I hope it wasn't me), but I think the right way to handle this option is with a simple boolean connected to ifdefs for the MAC driver. Come to think of it, it may have all started with the gianfar ptp module. In principle, the time stamping function of a MAC driver can be completely separate from the clock function, and indeed that is how the pair of gianfar drivers work. But for other hardware, it might not be practical to keep the functions separate, and in that case I would say, just keep it as one driver. Thanks, Richard PS It looks like no one is really looking after this PCH thing, so does anyone want to send me a board so I can take care of it? Let me know off list. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptp_pch: release chip->mem_base and chip->regs on error
On Thu, Oct 18, 2012 at 05:48:52PM +0800, Yuanhan Liu wrote: > Fix smatch warnings catched by Fengguang's 0-DAY system: > + drivers/ptp/ptp_pch.c:641 pch_probe() warn: 'chip->mem_base' was not > released on error > + drivers/ptp/ptp_pch.c:641 pch_probe() warn: 'chip->regs' was not released > on error > > Cc: Richard Cochran > Cc: David S. Miller > Signed-off-by: Yuanhan Liu Acked-by: Richard Cochran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question about context switch on arm Linux
On Sun, Oct 21, 2012 at 02:02:42PM +0800, caiyuqing wrote: > hi, all. > I have some questions about context switch on arm Linux (my target is > ARMv7-a). > 1. Does arm linux support FCSE to handle the context switch? No, mainline Linux does not support FCSE. However, you can use Gilles' unoffical (but working) FCSE branches at http://git.xenomai.org/?p=ipipe-gch.git;a=summary > 2. If using FCSE, that means the processes number limit is 128 and the > memory limit is 32MB per process, is that right? Yes and no. Gilles' patches offer a "strict mode" and a "best effort" mode. The strict mode does have the limitation, but the best effort mode does not. HTH, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question about context switch on arm Linux
On Sun, Oct 21, 2012 at 04:19:50PM +0800, caiyuqing wrote: > Richard, thanks for your reply. > mainline Linux doesn't support FCSE, if so, when kernel switch a > process to another(these two process share the same virtual memory > space), that means the vitrual-to-physical address should be > remaped, TLB shuold be invalid, CACHE should be flushed, right? Yes, and that is why you can measure quite a long context switching time when running Linux on ARMv4/5. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clk dereference in drivers/net/ethernet/ti/cpts.c
On Thu, Jan 03, 2013 at 11:20:52AM +0100, Julia Lawall wrote: > There has been a discussion recently about how the result of get_clk > should be an opaque handle, not a value that can be dereferenced: > > https://lkml.org/lkml/2012/12/20/105 > > There is such a dereference in drivers/net/ethernet/ti/cpts.c, in the > function cpts_clk_init: > > cpts->freq = cpts->refclk->recalc(cpts->refclk); > > It was not obvious to me, however, what API function should be used > instead, so I am just reporting the (potential) problem. This issue has been fixed in v3.8-rc2. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] Introducing Device Tree Overlays
On Fri, Jan 04, 2013 at 09:31:04PM +0200, Pantelis Antoniou wrote: > The following patchset introduces Device Tree overlays, a method > of dynamically altering the kernel's live Device Tree. It would be nice to know the motivation for this code. What is the use case? What problem or issue is being addressed? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] Introducing Device Tree Overlays
On Sat, Jan 05, 2013 at 12:16:51AM -0600, Joel A Fernandes wrote: > > The problem being addressed is discussed in this thread: > http://permalink.gmane.org/gmane.linux.kernel/1389017 Thanks for the link. Since the motivation is already documented in that post, why not add it into Documentation/devicetree/overlay-notes.txt as well? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptp_pch: eliminate a number of sparse warnings
On Tue, Mar 26, 2013 at 12:18:04PM +0900, kpark3...@gmail.com wrote: > From: Sahara > > This fixes a number of sparse warnings like: > warning: incorrect type in argument 2 (different address spaces) > expected void volatile [noderef] *addr > got unsigned int * > > warning: Using plain integer as NULL pointer > > Additionally this fixes a warning from checkpatch.pl like: > WARNING: sizeof pch_param.station should be sizeof(pch_param.station) > > Signed-off-by: Sahara Looks okay to me. Please post this to the netdev list. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] Move ntp state to be protected by timekeeping lock
On Mon, Mar 25, 2013 at 01:08:10PM -0700, John Stultz wrote: > This patchset makes the lock ownership lines less obvious, but I've > been sure to keep the ntp state static to ntp.c and instead provided > some accessors via ntp-internal.h that timekeping code can use to > make changes. The only really ugly part is that do_adjtimex() has > to split some of the logic between timekeeping.c and ntp.c in order > to really get the locking done correctly. I didn't find this too ugly or troublesome. The reshuffling you have here looks straightforward to me. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Fri, Jul 26, 2013 at 11:36:13AM -0500, Rob Herring wrote: > On 07/26/2013 10:49 AM, Olof Johansson wrote: > > On Fri, Jul 26, 2013 at 7:10 AM, Mark Brown wrote: > >> On Fri, Jul 26, 2013 at 03:09:29PM +0200, Richard Cochran wrote: > >> > >>> Unless I totally misunderstood, the thread is talking about letting > >>> established bindings change with each new kernel version. I am > >>> opposed to that. > >> > >> No, nobody is really saying that is a particularly good idea. There is > >> some debate about how we work out what an established binding is but > >> there's no serious suggestion that we don't want stable bindings. > > > > Yes, what Mark said -- _today_ all bindings are subject to change and > > can be changed in lockstep with the kernel. This has been necessary as > > part of development to sort out all of the various bootstrapping > > issues across platforms. This statement is an incredible piece of doublespeak. "Of course we want stable bindings. That is why 'all bindings are subject to change and can be changed in lockstep with the kernel.'" If you want to get away from the DT churn, then you have got to tell people in no uncertain terms that bindings in a released kernel are a stable ABI and must be supported into the future. If you need a playground for new ideas, refactoring platforms, etc, then go right ahead and create one, but please don't do this with released kernels. > This is absolutely not true on a global basis. Any binding used on > powerpc or sparc is not subject to change. Furthermore, there are ARM > platforms such as highbank where the bindings are expected to be stable. > That's not saying they don't change (new properties for SATA just > today), but they only change in a backwards compatible way. Right, and lets hope the arm tree can also take this stand. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote: > > Long term, final goal is likely to be close to what Russell is saying Why is this a long term goal? Start today. > -- nothing should go into the kernel tree unless the binding is in a > fully stable state. However, we have a transitional period between now > and then, and even when we're at the final state there will be need to > have some sort of sandbox for development and test of future bindings. Why not just set up a git tree right away? > Dealing with all that, as well as the actual process for locking in > bindings, is what needs to be sorted out. > > I think we're all in agreement that bindings that change over time are > nothing but pain, but we're arguing that in circles anyway. No. I keep saying, the bindings must be stable ABI, *today*. You keep saying, maybe later, but until then we will make things up as we go along. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote: > > Further, every other kernel release tended to break the board.c files, > just due to the usual kernel churn. Yes... > DT is much better, the stuff that can be described in DT is broader > and more thought tends to have been put into DT bindings than was put > into the old C methods. It has less churn, and what churn there is > seems simpler to follow. ... > Of course all this could have been done in C, but it wasn't/hasn't been.. You have identified the real issue: poor quality of the ARM board support process within the kernel. Churn is still churn, whether in DT or in platform devices, but the DT people promised to end the churn. At least with the platform code, I knew where to look to resolve issues. Thanks to DT, I now have three haystacks to search, namely boot loader, DT, and kernel. [ I disagree about the "more thought" part. The current discussion, coming years too late after the introduction of DT to ARM Linux, is contrary evidence enough. ] > Why would Freescale PPC be any different from the IBM PPC we use? We'd > use exactly the same techniques we use on ARM and PPC today and the > churn to the DT wouldn't be an operational problem in the field. I always suspected that the IBM powerpc Linux code was of higher quality. Freescale has been just awful. And that is just the point. No one is saying that DT cannot work. In theory (and in your experience) it is really wonderful. However, all this talk about "one day we will offer stable binding on ARM" already tells me what kind of quality to expect. > Why do you think our experiences are so different? Because the "embedded mindset" was used to develop the code on the platforms that I have been using. > *shrug* For embedded I am being *very pragmatic*. I don't need/want an > ABI boundary between the DT and the kernel. I don't need the DT to > statically describe the hardware. Yes, I know the kind of quality to expect from the embedded vendors. But that doesn't mean that mainline Linux should also stink. > Well, you know why. The DT schema used by the kernel changes over > time. Kirkwood just went through a massive change in schema in the > past few releases, and the same was true on our PPC platforms when > that was new. I find the very idea to be total unacceptable. This should never happen in the stable kernel. > I can't delay shipping while upstream sorts this out - so I know > *absolutely* that the DT schema will change. This has been planned for > and designed into the boot system and won't be a problem. > > Why would anyone do embedded any other way? Yep, that is the embedded way: ship it! We can do better than that. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote: > On Fri, Jul 26, 2013 at 06:54:33AM +0200, Richard Cochran wrote: > > I too work on commercial embedded systems, and DT has proven to be > > one gigantic *PITA*. > > Why do you think our experiences are so different? Here are a few recent examples: * What happens when one wants to boot vanilla kernel on the beaglebone? http://www.spinics.net/lists/arm-kernel/msg198431.html * Wanting already merged code to work is too much to ask. http://www.spinics.net/lists/linux-omap/msg79731.html * When people try in good faith to conduct methodical boot tests, DT is working against them. http://www.spinics.net/lists/linux-omap/msg79960.html Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote: > On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote: > > > [ I disagree about the "more thought" part. The current discussion, > > coming years too late after the introduction of DT to ARM Linux, is > > contrary evidence enough. ] > > We did have exactly the same discussion when the DT transition was > started - this isn't something that people only just realised might be > an issue. There was a deliberate decision to focus on getting the > technology deployed to the point where it could be used as a straight > replacement for board files and accept that sometimes the results won't > be perfect and that we may need to rework as a result. Can you tell a bit more about this decision? When was it made? Who made it? How was it made public? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Sat, Jul 27, 2013 at 12:36:02PM +0100, Mark Brown wrote: > On Sat, Jul 27, 2013 at 10:53:01AM +0200, Richard Cochran wrote: > > On Fri, Jul 26, 2013 at 11:15:24AM -0600, Jason Gunthorpe wrote: > > > > Why do you think our experiences are so different? > > > Here are a few recent examples: > > OK, let's go through these... Yes, lets, and remember the question was, why do I say that dealing with DT is such a PITA. > > * What happens when one wants to boot vanilla kernel on the beaglebone? > > > http://www.spinics.net/lists/arm-kernel/msg198431.html > > This actually sounds pretty good - glancing over the thread it seems you > were trying to boot a shiny new board that people were in the process of > trying to upstream support for and were just a bit too early. Device > tree doesn't seem to have made a difference either way here. Did you miss the part about CONFIG_ARM_APPENDED_DTB? > > * Wanting already merged code to work is too much to ask. > > > http://www.spinics.net/lists/linux-omap/msg79731.html > > Paul's reply here seems fairly clear - someone had merged a driver which > had been developed in an out of tree or pre-DT environment without DT > support so they just hadn't added DT support. Sadly doing that is new > feature development and so not appropriate for the stabalisation phase > of development. This is me asking for maintainers to take patches to fix a driver in version v3.7 where the driver merged in v3.4. The patches contain the missing DT part, and the maintainer rejects them, saying, no new features! Q: What the heck kind of process is that? A: DT process. Seriously, why is it too hard for y'all to insist on merging drivers only when they are really, truly ready (and don't forget the DT part, please). > > * When people try in good faith to conduct methodical boot tests, > > DT is working against them. > > > http://www.spinics.net/lists/linux-omap/msg79960.html > > Again I don't see anything particularly related to DT here but instead > do with using a SoC and board that are in the early phases of mainline > integration. It is ring around the rosie, DT, boot loader, and kernel. Understandably, Paul doesn't want to upgrade his boot loader. He says he is "not interested" in testing the boot loader, just the kernel. And, if you follow the sage of Paul's test reports, you will find him being told to update his boot loader and not to forget the delete old dtb files. So, like I said, it is a pity PITA. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Sat, Jul 27, 2013 at 10:57:09AM -0700, David Lang wrote: > On Sat, 27 Jul 2013, Richard Cochran wrote: > > >On Sat, Jul 27, 2013 at 11:40:18AM +0100, Mark Brown wrote: > >>On Sat, Jul 27, 2013 at 10:48:26AM +0200, Richard Cochran wrote: > >> > >>>[ I disagree about the "more thought" part. The current discussion, > >>> coming years too late after the introduction of DT to ARM Linux, is > >>> contrary evidence enough. ] > >> > >>We did have exactly the same discussion when the DT transition was > >>started - this isn't something that people only just realised might be > >>an issue. There was a deliberate decision to focus on getting the > >>technology deployed to the point where it could be used as a straight > >>replacement for board files and accept that sometimes the results won't > >>be perfect and that we may need to rework as a result. > > > >Can you tell a bit more about this decision? When was it made? Who > >made it? How was it made public? > > I remember seeing some of the discussion on linux-kernel at the > time. I believe there was also a LWN article. I must have missed it on lkml, although I do try to keep an eye on this topic. I did find http://lwn.net/Articles/414016/ http://lwn.net/Articles/426606/ but no word about unstable bindings. Maybe this was decided by the modern method of secret committee? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Sat, Jul 27, 2013 at 12:24:24PM +0200, Arend van Spriel wrote: > > That is a nice summary of how we got from null to now and Richard > seems to be simply saying: let's stop mucking about and make this a > project with a well-defined process of dealing with staging and > stable bindings and keep stable bindings stable. Yes, that is right. Frankly, I am really surprised and shocked at the cavalier attitude expressed here WRT DT bindings in released kernels. Think about the *users* of this code. Not everyone working with ARM Linux is a kernel developer or a DT guru. There is really no indication at all that the ARM Linux DT stuff released so far are not stable and trustworthy. It is not nice to provide such a mess, and the idea that we *must* have a mess because the whole system in still in development is bogus, IMHO. Just make sure that the mainline kernel is really working and that the DT bindings *there* are for keeps. It is your job as kernel developers. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Sat, Jul 27, 2013 at 11:51:06AM -0700, Tomasz Figa wrote: > On Saturday 27 of July 2013 20:31:01 Richard Cochran wrote: > > > > Frankly, I am really surprised and shocked at the cavalier attitude > > expressed here WRT DT bindings in released kernels. Think about the > > *users* of this code. Not everyone working with ARM Linux is a kernel > > developer or a DT guru. There is really no indication at all that the > > ARM Linux DT stuff released so far are not stable and trustworthy. Read the above again, please. > Well, it depends on how we use the DT. There are (at least) two possible > usage scenarios: > > a) using DT as direct replacement for board files - this means that you > are free to say that DTSes are strictly coupled with kernel version > and you are free to modify the bindings - see the analogy to board > files, where you could modify the platform data structures and could > not directly copy board file from one kernel version to another, > > b) using DT as an ABI - this is the original way, i.e. define stable > bindings and make sure that anu DTB built for older kernel will work, > with equal or greater set of functionality on newer kernels. > > Now I believe in this thread the point whether we should use a) or b) or a > combination of both has been raised. If you seriously want to pursue a) then you are thinking only of yourself. Please consider the needs of the people trying to use your code in actual practice. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Sun, Jul 28, 2013 at 11:12:53AM +0200, Tomasz Figa wrote: > I'm not really sure what effect on users this has. Maybe you should define > "users". ... > Care to explain this reasoning? Use Case User acquires a machine running ARM Linux version 3.x, with u-boot and dtb in a read only flash partition. The board boots and works just fine. However, for his application, the user requires a new kernel feature that appeared in version 3.y where y > x. He compiles the new kernel, and it also works. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Sun, Jul 28, 2013 at 03:39:56PM +0200, Tomasz Figa wrote: > There are many possible options: ... Wow, you totally ignored the use case. > Please note, though, I'm _not_ trying to convince you that this kind of > solutions is good, as I'm not convinced either. That's why we are > discussing this. And next you are going to convince me that updating my BIOS is a normal, expected, and necessary step in upgrading my kernel. No, thank you. Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Sun, Jul 28, 2013 at 10:09:57AM -0400, jonsm...@gmail.com wrote: > > 3.z kernel is free to alter the schema. But it will have to supply the > necessary quirks needed to keep those old dtb's functioning. The quirks idea sounds okay to me, if it can really provide forward compatibility. In practice, I doubt anyone will really spend the effort to make this work. I think it would be much easier to make sure the bindings are "future proof" in the first place. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Mon, Jul 29, 2013 at 09:31:23AM +0200, Maxime Ripard wrote: > > I'm afraid this kind of use case will never be properly supported, DT > stable ABI or not. > > Think about this: what kernel will actually be shipped in that board? > Most likely, it will be a BSP kernel from the vendor. Does the vendor > will have made that commitment to have a stable ABI for the DT? Will it > use the same bindings than mainline? Do we want to support all the crazy > bindings every vendor will come up with? > > I'm afraid the answer to these three questions will most of the time be > "no.". Yes, I know, and it is sad but true. We can't stop the vendors from shipping half-baked BSPs. I really don't mind that they do that. After all, they want to get *something* working when they launch their chips. > That doesn't mean we shouldn't aim for *mainline* having a stable DT > ABI, but that kind of use case doesn't seem very realistic to me. Right, we can and should do better. I got the beaglebone Ethernet working in mainline (not by writing the driver, but by complaining over and over again). I except that it will continue to work and not fall victim to some random DT change. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Mon, Jul 29, 2013 at 08:38:52PM +0200, Richard Cochran wrote: > > Right, we can and should do better. I got the beaglebone Ethernet > working in mainline (not by writing the driver, but by complaining > over and over again). I except that it will continue to work and not ^^ expect > fall victim to some random DT change. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Wed, Jul 31, 2013 at 12:59:59PM +0200, Tomasz Figa wrote: > On Wednesday 31 of July 2013 12:37:37 Maxime Bizon wrote: > > > > Board files are C code anyone has the skill to edit/understand/refactor. > > Moving to DT and keep them in tree tightly coupled with the kernel > > version just adds another layer of indirection for *no purpose*. +1 That is exactly what I tried to say. > > Linus started the whole thing some years ago by refusing to pull ARM > > tree [1]. Reread his post, what he wants is clearly b). > > > > Going a) does not solve any problem. You are just moving churn to > > somewhere else. We had board files churn, then defconfigs churn, DTS > > files (and associated drivers) will be next. And at this rate, we are headed for another Linus ultimatum, sooner or later. > > DT is self inflicted pain. It has to be for the greater good. > > It has several benefits over board files that I mentioned above, possible > without fully separating them from kernel tree. Every time a criticism is voiced about DT, the DT people stick their fingers in their ears and say, "NAH, NAH, NAH, I CAN'T HEAR YOU!" WRT to DT-as-platform-device, we would rather stick with the C code, please. Just pushing the configuration tables into an external form does not simplify the problem. In fact, it creates new problems by inviting the possibility of a bootloader/DT/kernel mismatch. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Wed, Jul 31, 2013 at 05:23:35PM +0200, Tomasz Figa wrote: > > I said it many, many times, that a) and b) I proposed are just two extremes. > It is unlikely that an extreme solution will be the best option to choose. I > am strongly for something in the middle, just like I wrote in several of my > previous replies. > > This is something that should be commented, not those extreme options. We are saying that pursuing a) is useless because it adds pain and complexity without adding benefit. I simply don't buy your argument that DT makes a better platform data, but that is besides the point. I had said, think about the users. You said, what users? I wrote a clear and concise use case. You said, lets think about a) and b) and all the shades of gray in between. In order to support the use case, you will have to provide a stable ABI. You can't have a compromise solution. At the end of the day, either you have a stable ABI, or you don't. It was apparent to me that the arm/dt thing has been meandering around since its inception, but what was surprising is that people were doing this on purpose, and now they are defending this. Why can't we get a firm commitment on having a stable ABI? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Wed, Jul 31, 2013 at 09:29:35PM +0200, Tomasz Figa wrote: > > I showed you two example solutions that could handle this use case without > stable binding ABI, just to prove that b) is not the only option (even if > it's the best one, which I continue to agree on, don't get me wrong). You only showed *one* solution (b) that satisfies the use case. The use case was: User acquires a machine running ARM Linux version 3.x, with u-boot and dtb in a read only flash partition. The board boots and works just ^ fine. However, for his application, the user requires a new kernel feature that appeared in version 3.y where y > x. He compiles the new kernel, and it also works. But you suggested: a) using DT as direct replacement for board files - this means that you are free to say that DTSes are strictly coupled with kernel version and you are free to modify the bindings - see the analogy to board files, where you could modify the platform data structures and could not directly copy board file from one kernel version to another, In the use case, the kernel is upgraded, but not the DTB. So this solution makes no sense. > I also added that the use case is not fully valid, The use case *is* valid. I am not inventing this just to be a pain. There are plenty of people unable or unwilling to upgrade their boot loader or DTB. You can say that you won't support it, but it is a use case from actual real life. > because you can't > magically define bindings for all future hardware, which means you can't > support the hardware using a DTB made before stable bindings for that > hardware have ever been introduced. Surely it is possible to develop and release a stable kernel and DT ABI for a given hardware? Once this is present, it is reasonable for users to expect forward compatibility from the DT system. > With all of this, I agreed that a DTB made for kernel 3.x, when used with > kernel 3.y (y > x) should provide the same or greater feature set than > used with kernel 3.x, in other words, this should cause no regressions. > Still, for new features, you will likely need to update the DTB. Yes, that is the idea. > So, again, to summarize, my view on this is as follows: > - there is a list of best practices for binding design and existing >stable bindings that can be used to help for designing new bindings, > - new bindings go through review process, > - after positive review, such bindings gets staging status, i.e. they are >marked as something that could change, > - after some period of time (we need to define this precisely) they get >frozen and can't be changed in a way that breaks compatibility any >more. In other words, they become ABI. > > What do you think? Sounds okay to me, but why bother with this marking business? Why not just have staging or development trees like every other subsystem? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/13] tile: support PTP using the tilegx mPIPE (IEEE 1588)
Chris,
This mail is a duplicate to you. I left off the CCs by mistake.
On Tue, Jul 23, 2013 at 04:05:48PM -0400, Chris Metcalf wrote:
> diff --git a/arch/tile/include/gxio/mpipe.h b/arch/tile/include/gxio/mpipe.h
> index b74f470..57f5ca2 100644
> --- a/arch/tile/include/gxio/mpipe.h
> +++ b/arch/tile/include/gxio/mpipe.h
> @@ -1733,4 +1733,17 @@ extern int
> gxio_mpipe_set_timestamp(gxio_mpipe_context_t *context,
> extern int gxio_mpipe_adjust_timestamp(gxio_mpipe_context_t *context,
> int64_t delta);
>
> +/* Adjust the mPIPE timestamp clock frequency.
> + *
> + * @param context An initialized mPIPE context.
> + * @param ppb A 32-bits signed PPB(Parts Per Billion) value to adjust.
> + * The absolute value of ppb must be less than or equal to 10,
> + * and should be larger then 3, otherwise just ignored because of
> + * the clock precision restriction.
30 ppm? That is not too good.
What do you mean by "should be larger"? The caller (from user space)
has no way to know about this limitation.
> + * @return If the call was successful, zero; otherwise, a negative error
> + * code.
> + */
> +extern int gxio_mpipe_adjust_timestamp_freq(gxio_mpipe_context_t *context,
> + int32_t ppb);
> +
> #endif /* !_GXIO_MPIPE_H_ */
...
> diff --git a/drivers/net/ethernet/tile/tilegx.c
> b/drivers/net/ethernet/tile/tilegx.c
> index f3c2d03..3d4406c 100644
> --- a/drivers/net/ethernet/tile/tilegx.c
> +++ b/drivers/net/ethernet/tile/tilegx.c
...
> @@ -1284,6 +1325,12 @@ static int tile_net_stop(struct net_device *dev)
> return 0;
> }
>
> +gxio_mpipe_context_t *get_mpipe_context(int index)
> +{
> + return ingress_irq < 0 ? NULL : &context;
So having a PHC depends on this IRQ having been initialized.
Why not just register the PHC in the same place?
> +}
> +EXPORT_SYMBOL_GPL(get_mpipe_context);
> +
> /* Determine the VA for a fragment. */
> static inline void *tile_net_frag_buf(skb_frag_t *f)
> {
...
> @@ -1727,6 +1777,12 @@ static void tile_net_tx_timeout(struct net_device *dev)
> /* Ioctl commands. */
> static int tile_net_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> {
> +#ifdef CONFIG_PTP_1588_CLOCK_TILEGX
> + if (cmd == SIOCSHWTSTAMP) {
> + /* Hardware timestamping was enabled by default. */
> + return 0;
This won't do. You need to update tx_type and rx_filter to reflect the
actual settings.
> + }
> +#endif
> return -EOPNOTSUPP;
> }
>
> diff --git a/drivers/net/ethernet/tile/tilegx_ptp.c
> b/drivers/net/ethernet/tile/tilegx_ptp.c
> new file mode 100644
> index 000..a188463
> --- /dev/null
> +++ b/drivers/net/ethernet/tile/tilegx_ptp.c
> @@ -0,0 +1,202 @@
> +/*
> + * PTP 1588 clock using the TILE-Gx.
> + *
> + * Copyright 2013 Tilera Corporation. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation, version 2.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
> + * NON INFRINGEMENT. See the GNU General Public License for
> + * more details.
> + *
> + * This source code is derived from ptp_ixp46x.c wrote by Richard Cochran.
"written by"
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define GBE_LINK_NR 4
> +
> +/* nanoseconds will be incremented each clock cycle. */
> +#define GBE_TIMER_INCREMENT 8
> +
> +
> +MODULE_AUTHOR("Tilera Corporation");
> +MODULE_DESCRIPTION("PTP clock using the TILE-Gx");
> +MODULE_LICENSE("GPL");
No need to make this a module at all. Just make the code conditionally
compiled, and register the clock along with your ingress_irq.
> +
> +
> +struct mpipe_clock {
> + struct ptp_clock *ptp_clock;
> + gxio_mpipe_context_t *context;
> + struct ptp_clock_info caps;
> + struct mutex lock;
> +};
> +
> +static struct mpipe_clock mpipe_clock;
> +
> +extern gxio_mpipe_context_t *get_mpipe_context(int index);
> +
> +/*
> + * Check if the context of mpipe device is valid.
> + */
This goes away with proper PHC registration as mentioned before.
> +static inline
Re: [PATCH 05/13] tile: support PTP using the tilegx mPIPE (IEEE 1588)
On Tue, Jul 23, 2013 at 04:05:48PM -0400, Chris Metcalf wrote: > diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig > index 5be73ba..255ed1a 100644 > --- a/drivers/ptp/Kconfig > +++ b/drivers/ptp/Kconfig > @@ -87,4 +87,14 @@ config PTP_1588_CLOCK_PCH > To compile this driver as a module, choose M here: the module > will be called ptp_pch. > > +config PTP_1588_CLOCK_TILEGX > +tristate "Tilera TILE-Gx mPIPE as PTP clock" > +select PTP_1588_CLOCK > +depends on TILEGX > +help > + This driver adds support for using the mPIPE as a PTP > + clock. This clock is only useful if your PTP programs are > + getting hardware time stamps on the PTP Ethernet packets > + using the SO_TIMESTAMPING API. > + Is this feature available on every TILEGX hardware variant? If not, then there needs to be some provision for that. Also, this option should probably appear under the main MAC option. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] tile: support PTP using the tilegx mPIPE (IEEE 1588)
On Thu, Jul 25, 2013 at 11:19:38AM -0400, Chris Metcalf wrote: > Signed-off-by: Chris Metcalf > --- > v2: > - Moved Kconfig stanza to drivers/ethernet/tile/Kconfig > - Clarify minimum and maximum frequency adjustments So if the requested frequency adjustment lies within the +/-30 ppm interval, then you return EINVAL? Maybe ERANGE would be better. Perhaps the driver should just round to the closest value it can support? Unfortunately, we don't have a way to communicate this kind of limitation to user space. > - Merge PTP support into tilegx.c driver source code directly > - Support SIOCSHWTSTAMP ioctl appopriately > - Rebased to be the last patch in the series to simplify development Anyhow, this looks much better to me now. Acked-by: Richard Cochran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote: > On Thu, Jul 25, 2013 at 07:05:48PM +0100, Stephen Warren wrote: > > > > I don't think having people "rely" on the bindings is the issue so much > > as the awareness that if they do, there will be compatibility issues for > > unstable bindings. > > As long as we can make sufficiently clear that trying to use an unstable > binding is going to be *very* painful, and not necessarily supported. Oh, man. The introduction of DT into ARM Linux was supposed to make everyone's life sooo much easier. Of course, based on experience with powerpc, I never believed it*, but still I would expect to hear that the DT bindings are, well, a *binding* contract between the board developer, boot loader, and the kernel. Once it is working with a particular kernel, a DT board description file should continue to work indefinitely with newer kernels. Anything less is a regression, pure and simple. If you go around changing the bindings willy nilly, then what is point of having DT at all? Thanks, Richard * http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/046963.html http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050255.html http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050256.html http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050264.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Thu, Jul 25, 2013 at 11:53:49AM -0700, Stephen Warren wrote: > On 07/25/2013 11:48 AM, Richard Cochran wrote: > > On Thu, Jul 25, 2013 at 07:29:20PM +0100, Mark Rutland wrote: > >> > >> As long as we can make sufficiently clear that trying to use an unstable > >> binding is going to be *very* painful, and not necessarily supported. IOW, its okay to break DT setups with every release, as long as we tell people first. Well, at least you are being honest about it now. > That's exactly why we're starting to think about which bindings should > be considered stable and immutable, and when that should happen. As Olof > pointed out, we haven't fully enforced that yet. Preferably bindings > will be marked stable very fast, but mistakes are always going to happen > in early development. ABIs are very hard. They are even harder if you cannot decide what the ABI is in the first place. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote: > We use DT has a kernel configuration input. Our environment is > designed to guarantee 100% that the kernel and DT match exactly. DT > very deliberately isn't an ABI boundary in our systems. It is nice that you use DT in that way, but that is not how DT is supposed to work. If you must keep your DT in sync with the kernel, then there is no advantage over the old platfrom device method. At least that had the virtue of being a C language interface (ABI), and some mistakes were be caught by the compiler. > We've been doing this for years and have a proven in the field track > record of upgrades from pre-2.6.16 to 3.7 and beyond with multiple > SOCs. The same bootloader that was shipped to support non-DT 2.6.16 > boots DT 3.7 just fine. Try that with Freescale PowerPCs. Good luck. Heck, even Paul's OMAP test reports have been spoiled by his not deleting old dtb files. Of course, that is his fault (and not DT's, no never). > For closed system embedded DT has proven *WONDERFUL*. I too work on commercial embedded systems, and DT has proven to be one gigantic *PITA*. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote: > > We use DT has a kernel configuration input. Our environment is > designed to guarantee 100% that the kernel and DT match exactly. DT > very deliberately isn't an ABI boundary in our systems. Think about what you just said. The DT describes the *hardware* not the kernel. Why should you ever need to update your DT at all? (Hint: the answer is, because the DT system is broken.) Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 17/36] PTP: convert class code to use dev_groups
On Wed, Jul 24, 2013 at 03:05:20PM -0700, Greg Kroah-Hartman wrote: > The dev_attrs field of struct class is going away soon, dev_groups > should be used instead. This converts the ptp class code to use the > correct field. > > Cc: Richard Cochran > Signed-off-by: Greg Kroah-Hartman > --- > > Richard, feel free to take this through your tree, or ACK it and I can take it > through mine. Please take this through your tree, as the PHC stuff has no tree of its own, apart from the networking tree. I did also test this patch briefly. Acked-by: Richard Cochran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]
On Fri, Jul 26, 2013 at 10:42:24AM +0100, David Woodhouse wrote: > On Fri, 2013-07-26 at 10:01 +0200, Richard Cochran wrote: > > On Thu, Jul 25, 2013 at 03:37:53PM -0600, Jason Gunthorpe wrote: > > > > > > We use DT has a kernel configuration input. Our environment is > > > designed to guarantee 100% that the kernel and DT match exactly. DT > > > very deliberately isn't an ABI boundary in our systems. > > > > Think about what you just said. > > > > The DT describes the *hardware* not the kernel. Why should you ever > > need to update your DT at all? > > Well, the nodes which describe hardware devices, according to the > bindings which form an ABI contract between DT and drivers, should not > normally change. Although they *can* change, if for example you change > the MAC address and that's stored there. Or you change the PHY you want > it to use. Or something like that. The *ABI* doesn't change, but the > data you express *using* that ABI can change. That's kind of the point. Unless I totally misunderstood, the thread is talking about letting established bindings change with each new kernel version. I am opposed to that. Of course, a user may want to change the values of his MAC addresses, if he needs to. But he should never have to change *how* he specifies those addresses. So, as long as everyone can agree to the principle that a working DT should remain working after a kernel upgrade, then I'll shut up. In actual fact, this is not the case today, nor was it ever so in the past, AFAICT, but it never hurts to set goals. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] igb: add a method to get the nic hw time stamping policy
On Sat, May 11, 2013 at 10:02:19PM +0800, Dong Zhu wrote:
>
> Currently kernel only support setting the hw time stamping policy
> through ioctl,now add a method to check which packets(Outgoing and
> Incoming) are time stamped by nic.
I don't really see a use case here. Applications needing time stamping
should just set the policy that they need.
> struct hwtstamp_config {
> + int rw;
Also, you can't just go adding fields to an ioctl.
> int flags;
> int tx_type;
> int rx_filter;
> --
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] igb: add a method to get the nic hw time stamping policy
On Sun, May 12, 2013 at 10:25:55PM +0800, Dong Zhu wrote:
> Thanks for your pointing out my mistakes of CodingStyle.
>
> > > struct hwtstamp_config {
> > >+ int rw;
>
> My initial idea was that the type of rw should be enum like tx_type, but I am
> not sure whther it is necessary to define a new enum, if this patch could
> be accpeted I will ask someone about the rw. At that time I will change
> the type of rw to bool or define a new enum, then convert the if to
> switch if necessary.
You cannot add any new field at all. That would break a userland ABI.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] igb: add a method to get the nic hw time stamping policy
On Mon, May 13, 2013 at 10:12:36AM +0800, Dong Zhu wrote: > > Can I use the 'flags' which members of hwtstamp_config to judge the > ioctl request instead ? If not could you plz give me a new way to > resolve this issue ? You could use the flags field, as it has no definition yet. But you still need to explain why this new functionality is needed in the first place: - You can query an interface's time stamping capabilities with the GET_TS_INFO ethtool command. - You can choose a setting with SIOCSHWTSTAMP. What more do you need? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples
On Fri, Apr 05, 2013 at 07:16:53PM +0100, Pawel Moll wrote: > Ok, so how about the code below? Disclaimer: this is just a proposal. > I'm not sure how welcomed would be an extra field in struct file, but > this makes the clocks ultimately flexible - one can "attach" the clock > to any arbitrary struct file. Alternatively we could mark a "clocked" > file with a special flag in f_mode and have some kind of lookup. Only a tiny minority of file instances will want to be clocks. Therefore I think adding the extra field will be a hard sell. The flag idea sounds harmless, but how do you perform the lookup? > Also, I can't stop thinking that the posix-clock.c shouldn't actually do > anything about the character device... The PTP core (as the model of > using character device seems to me just one of possible choices) could > do this on its own and have simple open/release attaching/detaching the > clock. This would remove a lot of "generic dev" code in the > posix-clock.c and all the optional cdev methods in struct posix_clock. > It's just a thought, though... Right, the chardev could be pushed into the PHC layer. The original idea of chardev clocks did have precedents, though, like hpet and rtc. > And a couple of questions to Richard... Isn't the kref_put() in > posix_clock_unregister() a bug? I'm not 100% but it looks like a simple > register->unregister sequence was making the ref count == -1, so the > delete_clock() won't be called. Well, posix_clock_register() -> kref_init() -> atomic_set(&kref->refcount, 1); So refcount is now 1 ... posix_clock_unregister() -> kref_put() -> kref_sub(count=1) -> atomic_sub_and_test((int) count, &kref->refcount) and refcount is now 0. Can't see how you would get -1 here. > And was there any particular reason that the ops in struct > posix_clock are *not* a pointer? One less run time indirection maybe? I don't really remember why or how we arrived at this. The whole PHC review took a year, with something like fifteen revisions. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples
On Mon, Apr 08, 2013 at 12:05:52PM -0700, John Stultz wrote: > > So thinking this through further, I'm worried we may _not_ be able > to eventually enable this to be a vdso as I had earlier hoped. > Mostly because I'm not sure how the fd -> file -> clock lookup could > be done in userland (any ideas?). How about a new clock operation, clock_install_vdso(), that lets the process arrange for one dynamic clock to be reflected in its vdso page? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: drm/i915: new warning (regression) in 3.7.10 and 3.8.3
On Tue, Apr 09, 2013 at 02:50:03PM +0200, Daniel Vetter wrote: > > This should be fixed with the above mentioned patch. The issue is that the > bios fumbles around with the output configuration behind our backs, so the > new paranoid modeset code in 3.7+ freaks out about the state mismatch > between sw and hw. > > The patch above should detect this situation and undo any bios-induced > damage. Even with the patch, I still am seeing the issue (in 3.8). Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring
On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote: > It will be only consistent once we've restored all the crtcs. Since a > bunch of other callers also want to just restore a single crtc, add a > boolean to disable checking only where it doesn't make sense. > > Note that intel_modeset_setup_hw_state already has a call to > intel_modeset_check_state at the end, so we don't reduce the amount of > checking. > > v2: Try harder not to create a big patch (Chris). To what does tree does this patch apply? Tried v3.8.6 and master d02a9a89. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring
On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote: > > It's written against drm-intel-next-queued at > > http://cgit.freedesktop.org/~danvet/drm-intel > > I've thought that it should apply pretty cleanly against older kernels, > too. Apparently it conflicts a bit in intel_modeset_setup_hw_state, you > can just do the s/intel_crtc_restore_mode/__intel_set_mode/ change > manually. I couldn't see right away how to fix it up, so I just compiled your drm-intel-next-queued plus this patch. If I close the netbook's lid and open it again, the screen is blank, no backlight, and the machine seems to be frozen. I think I can live with the warning. Thanks anyhow, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/15] ptp: PTP_1588_CLOCK_PCH depends on x86
On Tue, May 07, 2013 at 04:18:23PM +0200, Jiri Slaby wrote: > From: Jeff Mahoney > > The PCH EG20T is only compatible with Intel Atom processors so it > should depend on x86. This patch has been submitted before, https://patchwork.kernel.org/patch/2069071/ and at that time the reaction was that it is good to have drivers cross-compiled, if only for code quality reasons. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring
On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote: > That patch should crash at all, so this is not expected. Can you pls > check whether plain drm-intel-nightly is broken, too? I did try drm-intel-nightly just now (1dd83e3), and it also freezes the machine. I first verified that the power button shutdown is working (before starting X). Then, with X running, closing and reopening the lid results in a blank screen (no backlight) and a seemingly frozen box. > I'll quickly port the patch (in it's latest v3 version) to 3.9-rc > kernels for you to test. Okay, I'll try this next. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote: > > I've just tracked down and fixed an bug which can lead to a hard-hang > in the crtc restore code (which is used both in the lid handler when > opening and on resume). If you could please test this patch (on top of > drm-intel-nightly): > > https://patchwork.kernel.org/patch/2428971/ Okay, will do. > >> I'll quickly port the patch (in it's latest v3 version) to 3.9-rc > >> kernels for you to test. FWIW, this does work, no freeze, no warning, but instead: Apr 11 20:30:49 netboy laptop-mode: Laptop mode Apr 11 20:30:49 netboy laptop-mode: enabled, Apr 11 20:30:49 netboy laptop-mode: not active [unchanged] Apr 11 20:30:53 netboy kernel: [ 75.450783] [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode! Apr 11 20:30:53 netboy laptop-mode: Laptop mode Apr 11 20:30:53 netboy laptop-mode: enabled, Apr 11 20:30:53 netboy laptop-mode: not active [unchanged] Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote: > > I've just tracked down and fixed an bug which can lead to a hard-hang > in the crtc restore code (which is used both in the lid handler when > opening and on resume). If you could please test this patch (on top of > drm-intel-nightly): > > https://patchwork.kernel.org/patch/2428971/ Now I can confirm this works fine, with no warnings, errors, or freezes. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: Update gianfar_ptp after renaming
On Mon, Aug 27, 2012 at 10:38:33AM -0700, Joe Perches wrote:
> commit ec21e2ec36769 ("freescale: Move the Freescale drivers")
> moved the files, update the pattern.
Thanks for spotting this, Joe.
Acked-by: Richard Cochran
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6][RFC] Rework vsyscall to avoid truncation/rounding issue in timekeeping core
On Mon, Sep 17, 2012 at 05:20:41PM -0700, John Stultz wrote: > On 09/17/2012 04:49 PM, Andy Lutomirski wrote: > >2. There's nothing vsyscall-specific about the code in > >vclock_gettime.c. In fact, the VVAR macro should work just fine in > >kernel code. If you moved all this code into a header, then in-kernel > >uses could use it, and maybe even other arches could use it. Last > >time I checked, it seemed like vclock_gettime was considerably faster > >than whatever the in-kernel equivalent did. > I like the idea of unifying the implementations, but I'd want to > know more about why vclock_gettime was faster then the in-kernel > getnstimeofday(), since it might be due to the more limited locking > (we only update vsyscall data under the vsyscall lock, where as the > timekeeper lock is held for the entire execution of > update_wall_time()), or some of the optimizations in the vsyscall > code is focused on providing timespecs to userland, where as > in-kernel we also have to provide ktime_ts. This there a valid technical reason why each arch has its own vdso implementation? If not, I would suggest that the first step would be to refactor these into one C-language header. If this can be shared with kernel code, then all the better. It would make it a lot easier to fix the leap second thing, too. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6][RFC] Rework vsyscall to avoid truncation/rounding issue in timekeeping core
On Tue, Sep 18, 2012 at 11:29:50AM -0700, John Stultz wrote: > I believe its mostly historical, but on some architectures that > history has become an established ABI, making it technical. Fine, but what do you mean by "ABI?" Are you talking about magic addresses for functions? Without knowing the dirty details, what I imagine is a jump/branch from the arch-specific code into the common implementation. Can that be done? Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6][RFC] Rework vsyscall to avoid truncation/rounding issue in timekeeping core
On Wed, Sep 19, 2012 at 09:31:35AM -0700, John Stultz wrote: > On powerpc, I mean magic addresses where userland can find > structures that it can use to calculate time. ... > With powerpc, there is no arch specific kernel code involved, its > just a data structure the kernel exports that is accessible to > userland. The execution logic lives in userland libraries, or > sometimes application code itself. I took a brief look at arch/powerpc/kernel/vdso32/gettimeofday.S and arch/powerpc/kernel/vdso64/gettimeofday.S, and I see what looks a lot like functions $ find arch/powerpc/kernel/vdso* -name gettimeofday.S|xargs grep FUNCTION_BEGIN arch/powerpc/kernel/vdso32/gettimeofday.S:V_FUNCTION_BEGIN(__kernel_gettimeofday) arch/powerpc/kernel/vdso32/gettimeofday.S:V_FUNCTION_BEGIN(__kernel_clock_gettime) arch/powerpc/kernel/vdso32/gettimeofday.S:V_FUNCTION_BEGIN(__kernel_clock_getres) arch/powerpc/kernel/vdso64/gettimeofday.S:V_FUNCTION_BEGIN(__kernel_gettimeofday) arch/powerpc/kernel/vdso64/gettimeofday.S:V_FUNCTION_BEGIN(__kernel_clock_gettime) arch/powerpc/kernel/vdso64/gettimeofday.S:V_FUNCTION_BEGIN(__kernel_clock_getres) arch/powerpc/kernel/vdso64/gettimeofday.S:V_FUNCTION_BEGIN(__do_get_tspec) and I wonder whether these could be done in C instead. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6][RFC] Rework vsyscall to avoid truncation/rounding issue in timekeeping core
On Wed, Sep 19, 2012 at 02:11:02PM -0700, John Stultz wrote: > Now, I suspect the difficult part will be finding someone with the > time and interest to try get the vdso gettime working on ia64 (or > s390 or powerpc), and then try to unify the kernel side > implementation. Reducing the maintenance burden might not be > inspirational enough, especially if there is a small performance > cost along with it. Small performance cost verses correct time keeping? I couldn't help but notice all of the leap second issues and fixes that, once again, appeared this summer. It is great that John looks after this stuff, but I cannot avoid the image of Hans Brinker stopping leaks with his fingers. There is a way to fix this issue once and for all (as we discussed before). But in order to implement it, one would have to change all of the vdsos, too. So if there is way to refactor the vdsos, then I see this as a most "inspirational" task. > And also, all this discussion is a bit far afield of the patchset > I'm proposing here. :) I'd still like to hear any thoughts on it > from the various arch maintainers, otherwise I'll submit it to (Sorry for the continuing off topic rant) Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] posix-timers: Fix clock_adjtime to return timex data on success
On Thu, Jan 10, 2013 at 06:12:02PM +0100, Miroslav Lichvar wrote: > Copy the modified timex data back to the user also with positive return > values. This fixes reading of the CLOCK_REALTIME timex data when the > clock is in a non-zero state. > > Signed-off-by: Miroslav Lichvar Acked-by: Richard Cochran (Adding John Stultz on CC) > --- > kernel/posix-timers.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/posix-timers.c b/kernel/posix-timers.c > index 69185ae..10349d5 100644 > --- a/kernel/posix-timers.c > +++ b/kernel/posix-timers.c > @@ -997,7 +997,7 @@ SYSCALL_DEFINE2(clock_adjtime, const clockid_t, > which_clock, > > err = kc->clock_adj(which_clock, &ktx); > > - if (!err && copy_to_user(utx, &ktx, sizeof(ktx))) > + if (err >= 0 && copy_to_user(utx, &ktx, sizeof(ktx))) > return -EFAULT; > > return err; > -- > 1.7.11.7 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
m68k nommu: build failure in v3.8-rc2
I see the following error, using the .config inline, below. arch/m68k/mm/init.c: In function 'print_memmap': arch/m68k/mm/init.c:139:2: error: 'KMAP_START' undeclared (first use in this function) arch/m68k/mm/init.c:139:2: note: each undeclared identifier is reported only once for each function it appears in arch/m68k/mm/init.c:139:2: error: 'KMAP_END' undeclared (first use in this function) Looks to me like KMAP_START is only meant for the MMU case. This error was possibly caused by one of these two patches. $ pr v3.7.. -- arch/m68k/mm/init.c f50bf88 m68k: move to a single instance of free_initmem() dd1cb3a m68k: merge MMU and non-MMU versions of mm/init.c What is the right fix for this? Thanks, Richard --- # # Automatically generated file; DO NOT EDIT. # Linux/m68k 3.8.0-rc2 Kernel Configuration # CONFIG_M68K=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_CSUM=y CONFIG_TIME_LOW_RES=y CONFIG_NO_IOPORT=y # CONFIG_NO_DMA is not set CONFIG_ZONE_DMA=y CONFIG_HZ=100 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_FHANDLE is not set # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # # Timers subsystem # # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set CONFIG_UIDGID_CONVERTED=y # CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EXPERT=y CONFIG_HAVE_UID16=y # CONFIG_UID16 is not set # CONFIG_SYSCTL_SYSCALL is not set # CONFIG_KALLSYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_BASE_FULL is not set # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_AIO=y CONFIG_EMBEDDED=y # # Kernel Performance Events And Counters # # CONFIG_VM_EVENT_COUNTERS is not set # CONFIG_SLUB_DEBUG is not set CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_MMAP_ALLOW_UNINITIALIZED is not set # CONFIG_PROFILING is not set CONFIG_HAVE_CLK=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_MODULES_USE_ELF_RELA=y CONFIG_MODULES_USE_ELF_REL=y # # GCOV-based kernel profiling # # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_BASE_SMALL=1 # CONFIG_MODULES is not set CONFIG_BLOCK=y # CONFIG_LBDAF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_BSGLIB is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_EFI_PARTITION=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_INLINE_SPIN_UNLOCK_IRQ=y CONFIG_INLINE_READ_UNLOCK=y CONFIG_INLINE_READ_UNLOCK_IRQ=y CONFIG_INLINE_WRITE_UNLOCK=y CONFIG_INLINE_WRITE_UNLOCK_IRQ=y # CONFIG_FREEZER is not set # CONFIG_MMU is not set # # Platform setup # # # Processor Type # # CONFIG_M68KCLASSIC is not set CONFIG_COLDFIRE=y # CONFIG_M5206 is not set # CONFIG_M5206e is not set # CONFIG_M520x is not set CONFIG_M523x=y # CONFIG_M5249 is not set # CONFIG_M525x is not set # CONFIG_M5271 is not set # CONFIG_M5272 is not set # CONFIG_M5275 is not set # CONFIG_M528x is not set # CONFIG_M5307 is not set # CONFIG_M532x is not set # CONFIG_M5407 is not set # CONFIG_M547x is not set # CONFIG_M548x is not set # CONFIG_M5441x is not set # # Processor Specific Options # # CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set CONFIG_NODES_SHIFT=3 CONFIG_CPU_HAS_NO_BITFIELDS=y CONFIG_CPU_HAS_NO_MULDIV64=y CONFIG_HAVE_CACHE_SPLIT=y CONFIG_HAVE_IPSBAR=y CONFIG_CLOCK_SET=y CONFIG_CLOCK_FREQ=15000 CONFIG_CACHE_I=y # CONFIG_CACHE_D is not set # CONFIG_CACHE_BOTH is not set # # Machine Types # CONFIG_FREESCALE=y CONFIG_M5235EVB=y # CONFIG_SAVANTrosie1 is not set # # Machine Options # # CONFIG_UBOOT is not set CONFIG_4KSTACKS=y # # RAM configuration # CONFIG_RAMBASE=0x CONFIG_RAMSIZE=0x0100 CONFIG_VECTORBASE=0x0
Re: [PATCH] pps: hide more configuration symbols behind CONFIG_PPS
On Tue, Jan 08, 2013 at 01:59:22PM +0100, Florian Fainelli wrote: > This patch makes CONFIG_PPS_DEBUG and CONFIG_NTP_PPS be hidden if > CONFIG_PPS is not selected, such that we are not prompted for these > configuration options if CONFIG_PPS is not set. > > Signed-off-by: Florian Fainelli > --- > drivers/pps/Kconfig |4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/pps/Kconfig b/drivers/pps/Kconfig > index 982d16b..dc19fb4 100644 > --- a/drivers/pps/Kconfig > +++ b/drivers/pps/Kconfig > @@ -21,6 +21,8 @@ config PPS > To compile this driver as a module, choose M here: the module > will be called pps_core.ko. > > +if PPS > + If you add this "if" ... > config PPS_DEBUG > bool "PPS debugging messages" > depends on PPS ... then you should delete this redundant "depends". Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] make POSIX timers optional
On Tue, Sep 20, 2016 at 03:56:38PM -0400, Nicolas Pitre wrote: > - Add a warning for the case where PTP clock subsystem is modular and a > driver providing a clock is built-in rather than silently ignoring it. > Suggested by Jiri Benc. So I am really not happy with this. Here is a common embedded workflow, at least for me: 1. take some given Kconfig and get it running on the target. 2. for the given HW, change the modules into built-ins, and forget module loading After this series, if I don't pay enough attention to dmesg, then I have lost functionality that I had in step #1. That sucks, and it has nothing to do with the tinification option at all. It will bite even if I have no knowledge of it. That isn't acceptable to me. Thanks, Richard
Re: [PATCH v2 0/2] make POSIX timers optional
On Tue, Sep 20, 2016 at 10:25:56PM +0200, Richard Cochran wrote: > After this series, if I don't pay enough attention to dmesg, then I > have lost functionality that I had in step #1. That sucks, and it has > nothing to do with the tinification option at all. It will bite even > if I have no knowledge of it. That isn't acceptable to me. Can't you leave all the "select PTP_1588_CLOCK" alone and simply add #ifdef CONFIG_POSIX_TIMERS // global declarations #else // static inlines #endif to ptp_clock_kernel.h, and then sandwich ptp_clock.c in #ifdef CONFIG_POSIX_TIMERS ... #endif ? Thanks, Richard
Re: [PATCH v2 0/2] make POSIX timers optional
On Tue, Sep 20, 2016 at 06:47:02PM -0400, Nicolas Pitre wrote: > IMHO it is much nicer for the poor user configuring the kernel to have a > single configuration prompt for PTP support, and then have whatever > driver that can provide a PTP clock just do it (or omit it) based on > that single prompt. Prompting for PTP support for each individual > ethernet driver is silly. Embedded people like to optimize their systems. One pattern I have more than once is that a multihomed design designates a special PTP interface, often with a different HW than the other ports. PTP support adds extra code into the hot path, and for that reason people want to turn it off on interfaces that don't need it. So Thomas' idea is a better solution. It reduces the tinification in this area to a careful kernel configuration. Yes, that is more work to configure than having one "big red button" to push. The burden is on the tinification user to get this right, and that is the right way, IMHO. After all, this can be scripted, and such users have to configure very carefully in any case. Thanks, Richard
Re: [PATCH] ptp_clock: future-proofing drivers against PTP subsystem becoming optional
On Tue, Sep 20, 2016 at 07:25:58PM -0400, Nicolas Pitre wrote: > > Drivers must be ready to accept NULL from ptp_clock_register() if the > PTP clock subsystem is configured out. > > This patch documents that and ensures that all drivers cope well > with a NULL return. > > Signed-off-by: Nicolas Pitre > Reviewed-by: Eugenia Emantayev > > --- > > Let's have the basics merged now and work out the actual Kconfig issue > separately. Richard, if you agree with this patch, I think this could go > via the netdev tree. It looks ok to me. Acked-by: Richard Cochran
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote: > The ALSA API provides support for 'audio' timestamps (playback/capture rate > defined by audio subsystem) and 'system' timestamps (typically linked to > TSC/ART) with one option to take synchronized timestamps should the hardware > support them. Thanks for the info. I just skimmed Documentation/sound/alsa/timestamping.txt. That is fairly new, only since v4.1. Are then any apps in the wild that I can look at? AFAICT, OpenAVB, gstreamer, etc, don't use the new API. > The intent was that the 'audio' timestamps are translated to a shared time > reference managed in userspace by gPTP, which in turn would define if > (adaptive) audio sample rate conversion is needed. There is no support at > the moment for a 'play_at' function in ALSA, only means to control a > feedback loop. Documentation/sound/alsa/timestamping.txt says: If supported in hardware, the absolute link time could also be used to define a precise start time (patches WIP) Two questions: 1. Where are the patches? (If some are coming, I would appreciate being on CC!) 2. Can you mention specific HW that would support this? Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote: > Documentation/sound/alsa/timestamping.txt says: Examples of typestamping with HDaudio: 1. DMA timestamp, no compensation for DMA+analog delay $ ./audio_time -p --ts_type=1 Where is this "audio_time" program of which you speak? Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Mon, Jun 20, 2016 at 02:31:48PM +0200, Richard Cochran wrote: > Where is this "audio_time" program of which you speak? Never mind, found it in alsa-lib. I still would appreciate an answer to my other questions, though... Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Tue, Jun 21, 2016 at 07:54:32AM +0200, Takashi Iwai wrote: > > I still would appreciate an answer to my other questions, though... > > Currently HD-audio (both ASoC and legacy ones) are the only drivers > providing the link timestamp. In the recent code, it's PCM > get_time_info ops, so you can easily grep it. Yes, I found that myself, thanks. > HTH, No it doesn't help me, because I asked three questions, and none were about the link timestamp. Thanks, Richard
Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote: > You can experiment with the 'dma' and 'link' timestamps today on any > HDaudio-based device. Like I said the synchronized part has not been > upstreamed yet (delays + dependency on ART-to-TSC conversions that made it > in the kernel recently) Can you point me to any open source apps using the dma/link timestamps? Thanks, Richard
Re: [RFC PATCH 1/2] macb: Add 1588 support in Cadence GEM.
On Thu, Sep 08, 2016 at 10:22:43AM +0530, Harini Katakam wrote: > I cant be sure of the version of Cadence GEM used in SAMA5D2 > but these registers (sub ns increments alteast) only exist in > the IP version used in Zynq Ultrascale+ MPSoC. Then you need to find a way to make sure the driver only binds to the correct silicon. Thanks, Richard
Re: [RFC PATCH 1/2] macb: Add 1588 support in Cadence GEM.
On Thu, Sep 08, 2016 at 10:22:43AM +0530, Harini Katakam wrote: > >> + /* get GEM internal time */ > >> + sech = gem_readl(bp, TSH); > >> + secl = gem_readl(bp, TSL); > > > > Does reading TSH latch the time? The TRM is silent about that, and > > most other designs latch on reading the LSB. > > No, it does not latch the time. > When doing a read + adjust + write, this will > mean there's room for some error. It also means that you will have to handle when the TSL value overflows into TSH. That means reading TSH twice, once before and once after reading TSL and retrying if needed. The code as written above will produce apparent jumps backwards in time, whenever the overflow occurs between the two read operations. Thanks, Richard
Re: [RFC/PATCH] posix-timers: make them configurable
On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > Also given many other syscalls take clockids and the backing logic > isn't really getting removed (probably could cut the dynamic posix > clocks core with the same conditional), I wonder if you could get a > similar size win by taking a slightly more narrow cutting of the > subsystem. That way you could preserve the more useful clock_gettime() > functionality, but maybe stub out some of the less often used > functionality. I want to support tinification, but I also doubt the utility of removing clock_gettime() and clock_nanosleep(). I can't imagine ever building a user space without those. In fact, thinking about IoT, having good time is critical, and so these are the *last* functions I would remove when downsizing. Thanks, Richard
Re: [PATCH 3/9] net: ethernet: ti: cpts: rework initialization/deinitialization
On Wed, Sep 14, 2016 at 04:02:25PM +0300, Grygorii Strashko wrote:
> @@ -323,7 +307,7 @@ void cpts_rx_timestamp(struct cpts *cpts, struct sk_buff
> *skb)
> u64 ns;
> struct skb_shared_hwtstamps *ssh;
>
> - if (!cpts->rx_enable)
> + if (!cpts || !cpts->rx_enable)
> return;
This function is in the hot path, and you have added a pointless new
test. Don't do that.
> ns = cpts_find_ts(cpts, skb, CPTS_EV_RX);
> if (!ns)
> @@ -338,7 +322,7 @@ void cpts_tx_timestamp(struct cpts *cpts, struct sk_buff
> *skb)
> u64 ns;
> struct skb_shared_hwtstamps ssh;
>
> - if (!(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS))
> + if (!cpts || !(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS))
> return;
Same here.
> ns = cpts_find_ts(cpts, skb, CPTS_EV_TX);
> if (!ns)
> @@ -348,53 +332,102 @@ void cpts_tx_timestamp(struct cpts *cpts, struct
> sk_buff *skb)
> skb_tstamp_tx(skb, &ssh);
> }
>
> -int cpts_register(struct device *dev, struct cpts *cpts,
> - u32 mult, u32 shift)
> +int cpts_register(struct cpts *cpts)
> {
> int err, i;
> - unsigned long flags;
>
> - cpts->info = cpts_info;
> - cpts->clock = ptp_clock_register(&cpts->info, dev);
> - if (IS_ERR(cpts->clock)) {
> - err = PTR_ERR(cpts->clock);
> - cpts->clock = NULL;
> - return err;
> - }
> - spin_lock_init(&cpts->lock);
> -
> - cpts->cc.read = cpts_systim_read;
> - cpts->cc.mask = CLOCKSOURCE_MASK(32);
> - cpts->cc_mult = mult;
> - cpts->cc.mult = mult;
> - cpts->cc.shift = shift;
> + if (!cpts)
> + return -EINVAL;
Not hot path, but still silly. The caller should never pass NULL.
Thanks,
Richard
Re: [PATCH 4/9] net: ethernet: ti: cpts: move dt props parsing to cpts driver
On Wed, Sep 14, 2016 at 04:02:26PM +0300, Grygorii Strashko wrote: > Move DT properties parsing into CPTS driver to simplify consumer's > code and CPTS driver porting on other SoC in the future > (like Keystone 2). And just who is the consumer? > Signed-off-by: Grygorii Strashko > --- > drivers/net/ethernet/ti/cpsw.c | 16 +--- > drivers/net/ethernet/ti/cpsw.h | 2 -- > drivers/net/ethernet/ti/cpts.c | 29 ++--- > drivers/net/ethernet/ti/cpts.h | 5 +++-- > 4 files changed, 30 insertions(+), 22 deletions(-) You have more (+) than (-). I wouldn't call that a simplification. Thanks, Richard
Re: [PATCH 5/9] net: ethernet: ti: cpts: add return value to tx and rx timestamp funcitons
On Wed, Sep 14, 2016 at 04:02:27PM +0300, Grygorii Strashko wrote:
> From: WingMan Kwok
>
> Added return values in tx and rx timestamp funcitons facilitate the
> possibililies of timestamping by CPSW modules other than CPTS, such as
> packet accelerator on Keystone 2 devices.
I'm sorry, this is totally bogus.
> Signed-off-by: WingMan Kwok
> Signed-off-by: Grygorii Strashko
> ---
> drivers/net/ethernet/ti/cpts.c | 16 ++--
> drivers/net/ethernet/ti/cpts.h | 11 +++
> 2 files changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
> index 1ee64c6..970d4e2 100644
> --- a/drivers/net/ethernet/ti/cpts.c
> +++ b/drivers/net/ethernet/ti/cpts.c
> @@ -302,34 +302,38 @@ static u64 cpts_find_ts(struct cpts *cpts, struct
> sk_buff *skb, int ev_type)
> return ns;
> }
>
> -void cpts_rx_timestamp(struct cpts *cpts, struct sk_buff *skb)
> +int cpts_rx_timestamp(struct cpts *cpts, struct sk_buff *skb)
> {
> u64 ns;
> struct skb_shared_hwtstamps *ssh;
>
> if (!cpts || !cpts->rx_enable)
> - return;
> + return -EPERM;
EPERM? Come on.
> ns = cpts_find_ts(cpts, skb, CPTS_EV_RX);
> if (!ns)
> - return;
> + return -ENOENT;
> ssh = skb_hwtstamps(skb);
> memset(ssh, 0, sizeof(*ssh));
> ssh->hwtstamp = ns_to_ktime(ns);
> +
> + return 0;
> }
>
> -void cpts_tx_timestamp(struct cpts *cpts, struct sk_buff *skb)
> +int cpts_tx_timestamp(struct cpts *cpts, struct sk_buff *skb)
> {
> u64 ns;
> struct skb_shared_hwtstamps ssh;
>
> if (!cpts || !(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS))
> - return;
> + return -EPERM;
> ns = cpts_find_ts(cpts, skb, CPTS_EV_TX);
> if (!ns)
> - return;
> + return -ENOENT;
> memset(&ssh, 0, sizeof(ssh));
> ssh.hwtstamp = ns_to_ktime(ns);
> skb_tstamp_tx(skb, &ssh);
> +
> + return 0;
> }
>
> int cpts_register(struct cpts *cpts)
> diff --git a/drivers/net/ethernet/ti/cpts.h b/drivers/net/ethernet/ti/cpts.h
> index a865193..47026ec 100644
> --- a/drivers/net/ethernet/ti/cpts.h
> +++ b/drivers/net/ethernet/ti/cpts.h
> @@ -129,8 +129,8 @@ struct cpts {
> struct cpts_event pool_data[CPTS_MAX_EVENTS];
> };
>
> -void cpts_rx_timestamp(struct cpts *cpts, struct sk_buff *skb);
> -void cpts_tx_timestamp(struct cpts *cpts, struct sk_buff *skb);
> +int cpts_rx_timestamp(struct cpts *cpts, struct sk_buff *skb);
> +int cpts_tx_timestamp(struct cpts *cpts, struct sk_buff *skb);
> int cpts_register(struct cpts *cpts);
> void cpts_unregister(struct cpts *cpts);
> struct cpts *cpts_create(struct device *dev, void __iomem *regs,
> @@ -162,11 +162,14 @@ static inline bool cpts_is_tx_enabled(struct cpts *cpts)
> #else
> struct cpts;
>
> -static inline void cpts_rx_timestamp(struct cpts *cpts, struct sk_buff *skb)
> +static inline int cpts_rx_timestamp(struct cpts *cpts, struct sk_buff *skb)
> {
> + return -EOPNOTSUPP;
You are planning to check in the hot path if a compile time feature is
enabled?
Brilliant stuff.
> }
> -static inline void cpts_tx_timestamp(struct cpts *cpts, struct sk_buff *skb)
> +
> +static inline int cpts_tx_timestamp(struct cpts *cpts, struct sk_buff *skb)
> {
> + return -EOPNOTSUPP;
> }
>
> static inline
> --
> 2.9.3
>
Thanks,
Richard
Re: [PATCH 6/9] net: ethernet: ti: cpts: clean up event list if event pool is empty
On Wed, Sep 14, 2016 at 04:02:28PM +0300, Grygorii Strashko wrote:
> From: WingMan Kwok
>
> When a CPTS user does not exit gracefully by disabling cpts
> timestamping and leaving a joined multicast group, the system
> continues to receive and timestamps the ptp packets which eventually
> occupy all the event list entries. When this happns, the added code
> tries to remove some list entries which are expired.
>
> Signed-off-by: WingMan Kwok
> Signed-off-by: Grygorii Strashko
> ---
> drivers/net/ethernet/ti/cpts.c | 30 --
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
> index 970d4e2..ff8bb85 100644
> --- a/drivers/net/ethernet/ti/cpts.c
> +++ b/drivers/net/ethernet/ti/cpts.c
> @@ -57,22 +57,48 @@ static int cpts_fifo_pop(struct cpts *cpts, u32 *high,
> u32 *low)
> return -1;
> }
>
> +static int cpts_event_list_clean_up(struct cpts *cpts)
5 words, that is quite a mouth full. How about this instead?
static int cpts_purge_events(struct cpts *cpts);
> +{
> + struct list_head *this, *next;
> + struct cpts_event *event;
> + int removed = 0;
> +
> + list_for_each_safe(this, next, &cpts->events) {
> + event = list_entry(this, struct cpts_event, list);
> + if (event_expired(event)) {
> + list_del_init(&event->list);
> + list_add(&event->list, &cpts->pool);
> + ++removed;
> + }
> + }
> + return removed;
> +}
> +
> /*
> * Returns zero if matching event type was found.
> */
> static int cpts_fifo_read(struct cpts *cpts, int match)
> {
> int i, type = -1;
> + int removed;
No need for another variable, just change the return code above to
return removed ? 0 : -1;
and then you have ...
> u32 hi, lo;
> struct cpts_event *event;
>
> for (i = 0; i < CPTS_FIFO_DEPTH; i++) {
> if (cpts_fifo_pop(cpts, &hi, &lo))
> break;
> +
> if (list_empty(&cpts->pool)) {
> - pr_err("cpts: event pool is empty\n");
> - return -1;
> + removed = cpts_event_list_clean_up(cpts);
> + if (!removed) {
> + dev_err(cpts->dev,
> + "cpts: event pool is empty\n");
> + return -1;
> + }
if (cpts_purge_events(cpts)) {
dev_err(cpts->dev, "cpts: event pool empty\n");
return -1;
}
Notice how I avoided the ugly line break?
> + dev_dbg(cpts->dev,
> + "cpts: event pool cleaned up %d\n", removed);
> }
> +
> event = list_first_entry(&cpts->pool, struct cpts_event, list);
> event->tmo = jiffies + 2;
> event->high = hi;
> --
> 2.9.3
>
Thanks,
Richard
Re: [PATCH 7/9] net: ethernet: ti: cpts: calc mult and shift from refclk freq
On Wed, Sep 14, 2016 at 04:02:29PM +0300, Grygorii Strashko wrote:
> @@ -35,6 +33,8 @@ Optional properties:
> For example in dra72x-evm, pcf gpio has to be
> driven low so that cpsw slave 0 and phy data
> lines are connected via mux.
> +- cpts_clock_mult: Numerator to convert input clock ticks into
> nanoseconds
> +- cpts_clock_shift : Denominator to convert input clock ticks into
> nanoseconds
You should explain to the reader how these will be calculated when the
properties are missing.
> diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
> index ff8bb85..8046a21 100644
> --- a/drivers/net/ethernet/ti/cpts.c
> +++ b/drivers/net/ethernet/ti/cpts.c
> @@ -418,18 +418,60 @@ void cpts_unregister(struct cpts *cpts)
> clk_disable(cpts->refclk);
> }
>
> +static void cpts_calc_mult_shift(struct cpts *cpts)
> +{
> + u64 maxsec;
> + u32 freq;
> + u32 mult;
> + u32 shift;
> + u64 ns;
> + u64 frac;
Why so many new lines? This isn't good style. Please combine
variables of the same type into one line and sort the lists
alphabetically.
> + if (cpts->cc_mult || cpts->cc.shift)
> + return;
> +
> + freq = clk_get_rate(cpts->refclk);
> +
> + /* Calc the maximum number of seconds which we can run before
> + * wrapping around.
> + */
> + maxsec = cpts->cc.mask;
> + do_div(maxsec, freq);
> + if (!maxsec)
> + maxsec = 1;
> + else if (maxsec > 600 && cpts->cc.mask > UINT_MAX)
> + maxsec = 600;
> +
> + clocks_calc_mult_shift(&mult, &shift, freq, NSEC_PER_SEC, maxsec);
> +
> + cpts->cc_mult = mult;
> + cpts->cc.mult = mult;
> + cpts->cc.shift = shift;
> + /* Check calculations and inform if not precise */
Contrary to this comment, you are not making any kind of judgment
about whether the calculations are precise or not.
> + frac = 0;
> + ns = cyclecounter_cyc2ns(&cpts->cc, freq, cpts->cc.mask, &frac);
> +
> + dev_info(cpts->dev,
> + "CPTS: ref_clk_freq:%u calc_mult:%u calc_shift:%u error:%lld
> nsec/sec\n",
> + freq, cpts->cc_mult, cpts->cc.shift, (ns - NSEC_PER_SEC));
> +}
> +
Thanks,
Richard
