linux-next: Tree for Oct 14

linux-next: Tree for Oct 14

[Thierry Reding]

Hi all,

I've uploaded today's linux-next tree to the master branch of the
repository below:

        git://gitorious.org/thierryreding/linux-next.git

A next-20131014 tag is also provided for convenience.

Gained a few conflicts, but nothing too exciting. x86 and ARM default
configurations build fine. There were some build failures unrelated to
the merge, most of which I fixed and added as patches on top of the
final merge.

Thierry

linux-next: manual merge of the block tree

[Thierry Reding]

Today's linux-next merge of the block tree got conflicts in

	drivers/md/bcache/bcache.h
	drivers/md/bcache/bset.c
	drivers/md/bcache/journal.c
	drivers/md/bcache/request.c
	drivers/md/bcache/writeback.c

I've fixed them up (see below). Please verify that the resolution looks
good.

Thanks,
Thierry
---
diff --cc drivers/md/bcache/btree.c
index f42fc7e,117a12a..1ccb702
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@@ -633,10 -712,10 +707,10 @@@ static unsigned long bch_mca_scan(struc
  			break;
  
  		if (++i > 3 &&
- 		    !mca_reap(b, NULL, 0)) {
+ 		    !mca_reap(b, 0, false)) {
  			mca_data_free(b);
  			rw_unlock(true, b);
 -			--nr;
 +			freed++;
  		}
  	}
  
diff --cc drivers/md/bcache/request.c
index b6a74bc,231b108..9e1ff8e
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@@ -979,67 -1059,52 +1059,54 @@@ static void cached_dev_write(struct cac
  
  	if (should_writeback(dc, s->orig_bio,
  			     cache_mode(dc, bio),
- 			     s->op.skip)) {
- 		s->op.skip = false;
- 		s->writeback = true;
+ 			     s->iop.bypass)) {
+ 		s->iop.bypass = false;
+ 		s->iop.writeback = true;
  	}
  
- 	if (s->op.skip)
- 		goto skip;
- 
- 	trace_bcache_write(s->orig_bio, s->writeback, s->op.skip);
+ 	if (s->iop.bypass) {
+ 		s->iop.bio = s->orig_bio;
+ 		bio_get(s->iop.bio);
  
- 	if (!s->writeback) {
- 		s->op.cache_bio = bio_clone_bioset(bio, GFP_NOIO,
- 						   dc->disk.bio_split);
- 
- 		closure_bio_submit(bio, cl, s->d);
- 	} else {
+ 		if (!(bio->bi_rw & REQ_DISCARD) ||
+ 		    blk_queue_discard(bdev_get_queue(dc->bdev)))
+ 			closure_bio_submit(bio, cl, s->d);
+ 	} else if (s->iop.writeback) {
  		bch_writeback_add(dc);
 +		s->op.cache_bio = bio;
  
 -		if (s->iop.flush_journal) {
 +		if (bio->bi_rw & REQ_FLUSH) {
  			/* Also need to send a flush to the backing device */
 -			s->iop.bio = bio_clone_bioset(bio, GFP_NOIO,
 -						      dc->disk.bio_split);
 +			struct bio *flush = bio_alloc_bioset(0, GFP_NOIO,
 +							     dc->disk.bio_split);
  
 -			bio->bi_size = 0;
 -			bio->bi_vcnt = 0;
 -			closure_bio_submit(bio, cl, s->d);
 -		} else {
 -			s->iop.bio = bio;
 +			flush->bi_rw	= WRITE_FLUSH;
 +			flush->bi_bdev	= bio->bi_bdev;
 +			flush->bi_end_io = request_endio;
 +			flush->bi_private = cl;
 +
 +			closure_bio_submit(flush, cl, s->d);
  		}
- 	}
- out:
- 	closure_call(&s->op.cl, bch_insert_data, NULL, cl);
- 	continue_at(cl, cached_dev_write_complete, NULL);
- skip:
- 	s->op.skip = true;
- 	s->op.cache_bio = s->orig_bio;
- 	bio_get(s->op.cache_bio);
+ 	} else {
+ 		s->iop.bio = bio_clone_bioset(bio, GFP_NOIO,
+ 					      dc->disk.bio_split);
  
- 	if ((bio->bi_rw & REQ_DISCARD) &&
- 	    !blk_queue_discard(bdev_get_queue(dc->bdev)))
- 		goto out;
+ 		closure_bio_submit(bio, cl, s->d);
+ 	}
  
- 	closure_bio_submit(bio, cl, s->d);
- 	goto out;
+ 	closure_call(&s->iop.cl, bch_data_insert, NULL, cl);
+ 	continue_at(cl, cached_dev_write_complete, NULL);
  }
  
- static void request_nodata(struct cached_dev *dc, struct search *s)
+ static void cached_dev_nodata(struct closure *cl)
  {
- 	struct closure *cl = &s->cl;
+ 	struct search *s = container_of(cl, struct search, cl);
  	struct bio *bio = &s->bio.bio;
  
- 	if (bio->bi_rw & REQ_DISCARD) {
- 		request_write(dc, s);
- 		return;
- 	}
- 
- 	if (s->op.flush_journal)
- 		bch_journal_meta(s->op.c, cl);
+ 	if (s->iop.flush_journal)
+ 		bch_journal_meta(s->iop.c, cl);
  
+ 	/* If it's a flush, we send the flush to the backing device too */
  	closure_bio_submit(bio, cl, s->d);
  
  	continue_at(cl, cached_dev_bio_complete, NULL);

linux-next: manual merge of the drm-intel tree

[Thierry Reding]

Today's linux-next merge of the drm-intel tree got conflicts in:

	drivers/gpu/drm/i915/i915_dma.c
	drivers/gpu/drm/i915/intel_dp.c
	drivers/gpu/drm/i915/intel_drv.h

caused by commits e1264eb (Revert "drm/i915: Delay disabling of VGA memory
until vgacon->fbcon handoff is done") and ce35255 (drm/i915: Fix unclaimed
register access due to delayed VGA memory disable).

I fixed them up (see below). Please verify that the resolution looks good.

Thanks,
Thierry
---
diff --cc drivers/gpu/drm/i915/i915_dma.c
index 24640dc,42cddc1..f240150
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@@ -1350,6 -1358,13 +1355,8 @@@ static int i915_load_modeset_init(struc
  	 */
  	intel_fbdev_initial_config(dev);
  
 -	/*
 -	 * Must do this after fbcon init so that
 -	 * vgacon_save_screen() works during the handover.
 -	 */
 -	i915_disable_vga_mem(dev);
+ 	intel_display_power_put(dev, POWER_DOMAIN_VGA);
+ 
  	/* Only enable hotplug handling once the fbdev is fully set up. */
  	dev_priv->enable_hotplug_processing = true;
  
diff --cc drivers/gpu/drm/i915/intel_display.c
index 1fdf49c,4a8a2e4..fbd028e
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -10237,8 -10388,37 +10384,10 @@@ static void i915_disable_vga(struct drm
  	POSTING_READ(vga_reg);
  }
  
 -static void i915_enable_vga_mem(struct drm_device *dev)
 -{
 -	/* Enable VGA memory on Intel HD */
 -	if (HAS_PCH_SPLIT(dev)) {
 -		vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO);
 -		outb(inb(VGA_MSR_READ) | VGA_MSR_MEM_EN, VGA_MSR_WRITE);
 -		vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_IO |
 -						   VGA_RSRC_LEGACY_MEM |
 -						   VGA_RSRC_NORMAL_IO |
 -						   VGA_RSRC_NORMAL_MEM);
 -		vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
 -	}
 -}
 -
 -void i915_disable_vga_mem(struct drm_device *dev)
 -{
 -	/* Disable VGA memory on Intel HD */
 -	if (HAS_PCH_SPLIT(dev)) {
 -		vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO);
 -		outb(inb(VGA_MSR_READ) & ~VGA_MSR_MEM_EN, VGA_MSR_WRITE);
 -		vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_IO |
 -						   VGA_RSRC_NORMAL_IO |
 -						   VGA_RSRC_NORMAL_MEM);
 -		vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
 -	}
 -}
 -
  void intel_modeset_init_hw(struct drm_device *dev)
  {
+ 	struct drm_i915_private *dev_priv = dev->dev_private;
+ 
  	intel_prepare_ddi(dev);
  
  	intel_init_clock_gating(dev);
@@@ -10510,9 -10697,10 +10666,9 @@@ void i915_redisable_vga(struct drm_devi
  	    (I915_READ(HSW_PWR_WELL_DRIVER) & HSW_PWR_WELL_STATE_ENABLED) == 0)
  		return;
  
- 	if (I915_READ(vga_reg) != VGA_DISP_DISABLE) {
+ 	if (!(I915_READ(vga_reg) & VGA_DISP_DISABLE)) {
  		DRM_DEBUG_KMS("Something enabled VGA plane, disabling it\n");
  		i915_disable_vga(dev);
 -		i915_disable_vga_mem(dev);
  	}
  }
  
diff --cc drivers/gpu/drm/i915/intel_dp.c
index 98f3b64,bee09e1..c392ad2
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -1532,8 -1541,8 +1541,8 @@@ static void intel_edp_psr_setup(struct 
  	intel_edp_psr_write_vsc(intel_dp, &psr_vsc);
  
  	/* Avoid continuous PSR exit by masking memup and hpd */
- 	I915_WRITE(EDP_PSR_DEBUG_CTL, EDP_PSR_DEBUG_MASK_MEMUP |
+ 	I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
 -		   EDP_PSR_DEBUG_MASK_HPD);
 +		   EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
  
  	intel_dp->psr_setup_done = true;
  }
diff --cc drivers/gpu/drm/i915/intel_drv.h
index 39bfdb3,189257d..343f0fa
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@@ -714,116 -656,196 +656,197 @@@ void assert_fdi_rx_pll(struct drm_i915_
  		       enum pipe pipe, bool state);
  #define assert_fdi_rx_pll_enabled(d, p) assert_fdi_rx_pll(d, p, true)
  #define assert_fdi_rx_pll_disabled(d, p) assert_fdi_rx_pll(d, p, false)
- extern void assert_pipe(struct drm_i915_private *dev_priv, enum pipe pipe,
- 			bool state);
+ void assert_pipe(struct drm_i915_private *dev_priv, enum pipe pipe, bool state);
  #define assert_pipe_enabled(d, p) assert_pipe(d, p, true)
  #define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
+ void intel_write_eld(struct drm_encoder *encoder,
+ 		     struct drm_display_mode *mode);
+ unsigned long intel_gen4_compute_page_offset(int *x, int *y,
+ 					     unsigned int tiling_mode,
+ 					     unsigned int bpp,
+ 					     unsigned int pitch);
+ void intel_display_handle_reset(struct drm_device *dev);
+ void hsw_enable_pc8_work(struct work_struct *__work);
+ void hsw_enable_package_c8(struct drm_i915_private *dev_priv);
+ void hsw_disable_package_c8(struct drm_i915_private *dev_priv);
+ void intel_dp_get_m_n(struct intel_crtc *crtc,
+ 		      struct intel_crtc_config *pipe_config);
+ int intel_dotclock_calculate(int link_freq, const struct intel_link_m_n *m_n);
+ void
+ ironlake_check_encoder_dotclock(const struct intel_crtc_config *pipe_config,
+ 				int dotclock);
+ bool intel_crtc_active(struct drm_crtc *crtc);
+ void i915_disable_vga_mem(struct drm_device *dev);
+ void hsw_enable_ips(struct intel_crtc *crtc);
+ void hsw_disable_ips(struct intel_crtc *crtc);
+ 
+ 
+ /* intel_dp.c */
+ void intel_dp_init(struct drm_device *dev, int output_reg, enum port port);
+ bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
+ 			     struct intel_connector *intel_connector);
+ void intel_dp_start_link_train(struct intel_dp *intel_dp);
+ void intel_dp_complete_link_train(struct intel_dp *intel_dp);
+ void intel_dp_stop_link_train(struct intel_dp *intel_dp);
+ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
+ void intel_dp_encoder_destroy(struct drm_encoder *encoder);
+ void intel_dp_check_link_status(struct intel_dp *intel_dp);
+ bool intel_dp_compute_config(struct intel_encoder *encoder,
+ 			     struct intel_crtc_config *pipe_config);
+ bool intel_dpd_is_edp(struct drm_device *dev);
+ void ironlake_edp_backlight_on(struct intel_dp *intel_dp);
+ void ironlake_edp_backlight_off(struct intel_dp *intel_dp);
+ void ironlake_edp_panel_on(struct intel_dp *intel_dp);
+ void ironlake_edp_panel_off(struct intel_dp *intel_dp);
+ void ironlake_edp_panel_vdd_on(struct intel_dp *intel_dp);
+ void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync);
+ void intel_edp_psr_enable(struct intel_dp *intel_dp);
+ void intel_edp_psr_disable(struct intel_dp *intel_dp);
+ void intel_edp_psr_update(struct drm_device *dev);
+ 
+ 
+ /* intel_dsi.c */
+ bool intel_dsi_init(struct drm_device *dev);
+ 
  
- extern void intel_init_clock_gating(struct drm_device *dev);
- extern void intel_suspend_hw(struct drm_device *dev);
- extern void intel_write_eld(struct drm_encoder *encoder,
- 			    struct drm_display_mode *mode);
- extern void intel_prepare_ddi(struct drm_device *dev);
- extern void hsw_fdi_link_train(struct drm_crtc *crtc);
- extern void intel_ddi_init(struct drm_device *dev, enum port port);
- extern enum port intel_ddi_get_encoder_port(struct intel_encoder *intel_encoder);
- 
- /* For use by IVB LP watermark workaround in intel_sprite.c */
- extern void intel_update_watermarks(struct drm_crtc *crtc);
- extern void intel_update_sprite_watermarks(struct drm_plane *plane,
- 					   struct drm_crtc *crtc,
- 					   uint32_t sprite_width, int pixel_size,
- 					   bool enabled, bool scaled);
- 
- extern unsigned long intel_gen4_compute_page_offset(int *x, int *y,
- 						    unsigned int tiling_mode,
- 						    unsigned int bpp,
- 						    unsigned int pitch);
- 
- extern int intel_sprite_set_colorkey(struct drm_device *dev, void *data,
- 				     struct drm_file *file_priv);
- extern int intel_sprite_get_colorkey(struct drm_device *dev, void *data,
- 				     struct drm_file *file_priv);
- 
- /* Power-related functions, located in intel_pm.c */
- extern void intel_init_pm(struct drm_device *dev);
- /* FBC */
- extern bool intel_fbc_enabled(struct drm_device *dev);
- extern void intel_update_fbc(struct drm_device *dev);
- /* IPS */
- extern void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
- extern void intel_gpu_ips_teardown(void);
- 
- /* Power well */
- extern int i915_init_power_well(struct drm_device *dev);
- extern void i915_remove_power_well(struct drm_device *dev);
- 
- extern bool intel_display_power_enabled(struct drm_device *dev,
- 					enum intel_display_power_domain domain);
- extern void intel_display_power_get(struct drm_device *dev,
- 				    enum intel_display_power_domain domain);
- extern void intel_display_power_put(struct drm_device *dev,
- 				    enum intel_display_power_domain domain);
- extern void intel_init_power_well(struct drm_device *dev);
- extern void intel_set_power_well(struct drm_device *dev, bool enable);
- extern void intel_resume_power_well(struct drm_device *dev);
- extern void intel_enable_gt_powersave(struct drm_device *dev);
- extern void intel_disable_gt_powersave(struct drm_device *dev);
- extern void ironlake_teardown_rc6(struct drm_device *dev);
+ /* intel_dvo.c */
+ void intel_dvo_init(struct drm_device *dev);
+ 
+ 
+ /* legacy fbdev emulation in intel_fbdev.c */
+ #ifdef CONFIG_DRM_I915_FBDEV
+ extern int intel_fbdev_init(struct drm_device *dev);
+ extern void intel_fbdev_initial_config(struct drm_device *dev);
+ extern void intel_fbdev_fini(struct drm_device *dev);
+ extern void intel_fbdev_set_suspend(struct drm_device *dev, int state);
+ extern void intel_fbdev_output_poll_changed(struct drm_device *dev);
+ extern void intel_fbdev_restore_mode(struct drm_device *dev);
+ #else
+ static inline int intel_fbdev_init(struct drm_device *dev)
+ {
+ 	return 0;
+ }
+ 
+ static inline void intel_fbdev_initial_config(struct drm_device *dev)
+ {
+ }
+ 
+ static inline void intel_fbdev_fini(struct drm_device *dev)
+ {
+ }
+ 
+ static inline void intel_fbdev_set_suspend(struct drm_device *dev, int state)
+ {
+ }
+ 
+ static inline void intel_fbdev_restore_mode(struct drm_device *dev)
+ {
+ }
+ #endif
+ 
+ /* intel_hdmi.c */
+ void intel_hdmi_init(struct drm_device *dev, int hdmi_reg, enum port port);
+ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
+ 			       struct intel_connector *intel_connector);
+ struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
+ bool intel_hdmi_compute_config(struct intel_encoder *encoder,
+ 			       struct intel_crtc_config *pipe_config);
+ 
+ 
+ /* intel_lvds.c */
+ void intel_lvds_init(struct drm_device *dev);
+ bool intel_is_dual_link_lvds(struct drm_device *dev);
+ 
+ 
+ /* intel_modes.c */
+ int intel_connector_update_modes(struct drm_connector *connector,
+ 				 struct edid *edid);
+ int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter *adapter);
+ void intel_attach_force_audio_property(struct drm_connector *connector);
+ void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
+ 
+ 
+ /* intel_overlay.c */
+ void intel_setup_overlay(struct drm_device *dev);
+ void intel_cleanup_overlay(struct drm_device *dev);
+ int intel_overlay_switch_off(struct intel_overlay *overlay);
+ int intel_overlay_put_image(struct drm_device *dev, void *data,
+ 			    struct drm_file *file_priv);
+ int intel_overlay_attrs(struct drm_device *dev, void *data,
+ 			struct drm_file *file_priv);
+ 
+ 
+ /* intel_panel.c */
+ int intel_panel_init(struct intel_panel *panel,
+ 		     struct drm_display_mode *fixed_mode);
+ void intel_panel_fini(struct intel_panel *panel);
+ void intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
+ 			    struct drm_display_mode *adjusted_mode);
+ void intel_pch_panel_fitting(struct intel_crtc *crtc,
+ 			     struct intel_crtc_config *pipe_config,
+ 			     int fitting_mode);
+ void intel_gmch_panel_fitting(struct intel_crtc *crtc,
+ 			      struct intel_crtc_config *pipe_config,
+ 			      int fitting_mode);
+ void intel_panel_set_backlight(struct drm_device *dev, u32 level, u32 max);
+ int intel_panel_setup_backlight(struct drm_connector *connector);
+ void intel_panel_enable_backlight(struct drm_device *dev, enum pipe pipe);
+ void intel_panel_disable_backlight(struct drm_device *dev);
+ void intel_panel_destroy_backlight(struct drm_device *dev);
+ enum drm_connector_status intel_panel_detect(struct drm_device *dev);
+ 
+ 
+ /* intel_pm.c */
+ void intel_init_clock_gating(struct drm_device *dev);
+ void intel_suspend_hw(struct drm_device *dev);
+ void intel_update_watermarks(struct drm_crtc *crtc);
+ void intel_update_sprite_watermarks(struct drm_plane *plane,
+ 				    struct drm_crtc *crtc,
+ 				    uint32_t sprite_width, int pixel_size,
+ 				    bool enabled, bool scaled);
+ void intel_init_pm(struct drm_device *dev);
+ bool intel_fbc_enabled(struct drm_device *dev);
+ void intel_update_fbc(struct drm_device *dev);
+ void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
+ void intel_gpu_ips_teardown(void);
+ int i915_init_power_well(struct drm_device *dev);
+ void i915_remove_power_well(struct drm_device *dev);
+ bool intel_display_power_enabled(struct drm_device *dev,
+ 				 enum intel_display_power_domain domain);
+ void intel_display_power_get(struct drm_device *dev,
+ 			     enum intel_display_power_domain domain);
+ void intel_display_power_put(struct drm_device *dev,
+ 			     enum intel_display_power_domain domain);
+ void intel_init_power_well(struct drm_device *dev);
+ void intel_set_power_well(struct drm_device *dev, bool enable);
+ void intel_enable_gt_powersave(struct drm_device *dev);
+ void intel_disable_gt_powersave(struct drm_device *dev);
+ void ironlake_teardown_rc6(struct drm_device *dev);
  void gen6_update_ring_freq(struct drm_device *dev);
+ void gen6_rps_idle(struct drm_i915_private *dev_priv);
+ void gen6_rps_boost(struct drm_i915_private *dev_priv);
+ void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv);
+ void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv);
  
- extern bool intel_ddi_get_hw_state(struct intel_encoder *encoder,
- 				   enum pipe *pipe);
- extern int intel_ddi_get_cdclk_freq(struct drm_i915_private *dev_priv);
- extern void intel_ddi_pll_init(struct drm_device *dev);
- extern void intel_ddi_enable_transcoder_func(struct drm_crtc *crtc);
- extern void intel_ddi_disable_transcoder_func(struct drm_i915_private *dev_priv,
- 					      enum transcoder cpu_transcoder);
- extern void intel_ddi_enable_pipe_clock(struct intel_crtc *intel_crtc);
- extern void intel_ddi_disable_pipe_clock(struct intel_crtc *intel_crtc);
- extern void intel_ddi_setup_hw_pll_state(struct drm_device *dev);
- extern bool intel_ddi_pll_mode_set(struct drm_crtc *crtc);
- extern void intel_ddi_put_crtc_pll(struct drm_crtc *crtc);
- extern void intel_ddi_set_pipe_settings(struct drm_crtc *crtc);
- extern void intel_ddi_prepare_link_retrain(struct drm_encoder *encoder);
- extern bool
- intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
- extern void intel_ddi_fdi_disable(struct drm_crtc *crtc);
- 
- extern void intel_display_handle_reset(struct drm_device *dev);
- extern bool intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev,
- 						  enum pipe pipe,
- 						  bool enable);
- extern bool intel_set_pch_fifo_underrun_reporting(struct drm_device *dev,
- 						 enum transcoder pch_transcoder,
- 						 bool enable);
- 
- extern void intel_edp_psr_enable(struct intel_dp *intel_dp);
- extern void intel_edp_psr_disable(struct intel_dp *intel_dp);
- extern void intel_edp_psr_update(struct drm_device *dev);
- extern void hsw_disable_lcpll(struct drm_i915_private *dev_priv,
- 			      bool switch_to_fclk, bool allow_power_down);
- extern void hsw_restore_lcpll(struct drm_i915_private *dev_priv);
- extern void ilk_enable_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask);
- extern void ilk_disable_gt_irq(struct drm_i915_private *dev_priv,
- 			       uint32_t mask);
- extern void snb_enable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask);
- extern void snb_disable_pm_irq(struct drm_i915_private *dev_priv,
- 			       uint32_t mask);
- extern void hsw_enable_pc8_work(struct work_struct *__work);
- extern void hsw_enable_package_c8(struct drm_i915_private *dev_priv);
- extern void hsw_disable_package_c8(struct drm_i915_private *dev_priv);
- extern void hsw_pc8_disable_interrupts(struct drm_device *dev);
- extern void hsw_pc8_restore_interrupts(struct drm_device *dev);
- extern void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv);
- extern void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv);
- extern void intel_dp_get_m_n(struct intel_crtc *crtc,
- 			     struct intel_crtc_config *pipe_config);
- extern int intel_dotclock_calculate(int link_freq,
- 				    const struct intel_link_m_n *m_n);
- extern void ironlake_check_encoder_dotclock(const struct intel_crtc_config *pipe_config,
- 					    int dotclock);
  
- extern bool intel_crtc_active(struct drm_crtc *crtc);
+ /* intel_sdvo.c */
+ bool intel_sdvo_init(struct drm_device *dev, uint32_t sdvo_reg, bool is_sdvob);
+ 
+ 
+ /* intel_sprite.c */
+ int intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane);
+ void intel_flush_primary_plane(struct drm_i915_private *dev_priv,
+ 			       enum plane plane);
+ void intel_plane_restore(struct drm_plane *plane);
+ void intel_plane_disable(struct drm_plane *plane);
+ int intel_sprite_set_colorkey(struct drm_device *dev, void *data,
+ 			      struct drm_file *file_priv);
+ int intel_sprite_get_colorkey(struct drm_device *dev, void *data,
+ 			      struct drm_file *file_priv);
+ 
++bool intel_crtc_active(struct drm_crtc *crtc);
+ 
+ /* intel_tv.c */
+ void intel_tv_init(struct drm_device *dev);
  
  #endif /* __INTEL_DRV_H__ */

linux-next: manual merge of the drm tree

[Thierry Reding]

Today's linux-next merge of the drm tree got conflicts in

	drivers/gpu/drm/i915/intel_drv.h

caused by commits e1264eb (Revert "drm/i915: Delay disabling of VGA memory
until vgacon->fbcon handoff is done"), 20ddf66 (drm/i915: Make
intel_crtc_active() available outside intel_pm.c), 18442d0 (drm/i915: Fix
port_clock and adjusted_mode.clock readout all over), 6878da0 (drm/i915:
Add intel_dotclock_calculate()) and eb14cb7 (drm/i915: Add state readout
and checking for has_dp_encoder and dp_m_n).

I fixed them up (see below). Please verify that the resolution looks good.

Thanks,
Thierry
---
diff --cc drivers/gpu/drm/i915/intel_drv.h
index 9b7b68f,287bbef..39bfdb3
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@@ -793,5 -817,14 +817,13 @@@ extern void hsw_pc8_disable_interrupts(
  extern void hsw_pc8_restore_interrupts(struct drm_device *dev);
  extern void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv);
  extern void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv);
+ extern void intel_dp_get_m_n(struct intel_crtc *crtc,
+ 			     struct intel_crtc_config *pipe_config);
+ extern int intel_dotclock_calculate(int link_freq,
+ 				    const struct intel_link_m_n *m_n);
+ extern void ironlake_check_encoder_dotclock(const struct intel_crtc_config *pipe_config,
+ 					    int dotclock);
+ 
+ extern bool intel_crtc_active(struct drm_crtc *crtc);
 -extern void i915_disable_vga_mem(struct drm_device *dev);
  
  #endif /* __INTEL_DRV_H__ */

linux-next: manual merge of th imx-mxs tree

[Thierry Reding]

Today's linux-next merge of the imx-mxs tree got conflicts in:

	arch/arm/mach-imx/clk-imx51-imx53.c
	arch/arm/mach-imx/mach-imx6q.c

caused by commits 0efe995 (ARM: mach-imx: clk-imx51-imx53: Retrieve base
address and irq from dt) and 4d9d18a (ARM: imx: remove custom .init_time
hook).

This looks like the same conflict as last week, only this time I think I
actually fixed it up properly. Please verify that the resolution looks
good.

Thanks,
Thierry
---
diff --cc arch/arm/mach-imx/clk-imx51-imx53.c
index ceaac9c,03ca2e3..ce37af2
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@@ -11,9 -11,11 +11,12 @@@
  #include <linux/clk.h>
  #include <linux/io.h>
  #include <linux/clkdev.h>
 +#include <linux/clk-provider.h>
  #include <linux/of.h>
  #include <linux/err.h>
+ #include <linux/of.h>
+ #include <linux/of_address.h>
+ #include <linux/of_irq.h>
  
  #include "crm-regs-imx5.h"
  #include "clk.h"
@@@ -464,16 -468,13 +467,17 @@@ int __init mx51_clocks_init(unsigned lo
  	return 0;
  }
  
 -int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 -			unsigned long rate_ckih1, unsigned long rate_ckih2)
 +static void __init mx51_clocks_init_dt(struct device_node *np)
 +{
 +	mx51_clocks_init(0, 0, 0, 0);
 +}
 +CLK_OF_DECLARE(imx51_ccm, "fsl,imx51-ccm", mx51_clocks_init_dt);
 +
 +static void __init mx53_clocks_init(struct device_node *np)
  {
- 	int i;
+ 	int i, irq;
  	unsigned long r;
 -	struct device_node *np;
+ 	void __iomem *base;
  
  	clk[pll1_sw] = imx_clk_pllv2("pll1_sw", "osc", MX53_DPLL1_BASE);
  	clk[pll2_sw] = imx_clk_pllv2("pll2_sw", "osc", MX53_DPLL2_BASE);
@@@ -568,5 -567,22 +569,11 @@@
  
  	r = clk_round_rate(clk[usboh3_per_gate], 54000000);
  	clk_set_rate(clk[usboh3_per_gate], r);
+ 
+ 	np = of_find_compatible_node(NULL, NULL, "fsl,imx53-gpt");
+ 	base = of_iomap(np, 0);
+ 	WARN_ON(!base);
+ 	irq = irq_of_parse_and_map(np, 0);
+ 	mxc_timer_init(base, irq);
 -
 -	return 0;
 -}
 -
 -int __init mx51_clocks_init_dt(void)
 -{
 -	return mx51_clocks_init(0, 0, 0, 0);
 -}
 -
 -int __init mx53_clocks_init_dt(void)
 -{
 -	return mx53_clocks_init(0, 0, 0, 0);
  }
 +CLK_OF_DECLARE(imx53_ccm, "fsl,imx53-ccm", mx53_clocks_init);
diff --cc arch/arm/mach-imx/mach-imx6q.c
index 3be0fa0,53e70f4..0f9f241
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@@ -11,9 -11,10 +11,8 @@@
   */
  
  #include <linux/clk.h>
 -#include <linux/clk-provider.h>
  #include <linux/clkdev.h>
 -#include <linux/clocksource.h>
  #include <linux/cpu.h>
- #include <linux/delay.h>
  #include <linux/export.h>
  #include <linux/init.h>
  #include <linux/io.h>
@@@ -190,8 -133,13 +131,16 @@@ static void __init imx6q_1588_init(void
  
  static void __init imx6q_init_machine(void)
  {
+ 	struct device *parent;
+ 
 +	imx_print_silicon_rev(cpu_is_imx6dl() ? "i.MX6DL" : "i.MX6Q",
- 			      imx6q_revision());
++			      imx_get_soc_revision());
++
+ 	mxc_arch_reset_init_dt();
+ 
+ 	parent = imx_soc_device_init();
+ 	if (parent == NULL)
+ 		pr_warn("failed to initialize soc device\n");
  
  	imx6q_enet_phy_init();
  

linux-next: manual merge of the omap_dss2 tree

[Thierry Reding]

Today's linux-next merge of the omap_dss2 tree got conflicts in

	drivers/video/omap2/dss/hdmi4_core.c
	drivers/video/omap2/dss/hdmi4_core.h

caused by commits ef26958 (omapdss: HDMI: Rename hdmi driver files to nicer
names) and a few others that I didn't quite track down. But given that the
diff of the merge commit is empty I guess everything's well.

Thanks,
Thierry

Re: linux-next: manual merge of the omap_dss2 tree

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

Hi,

On 14/10/13 17:48, Thierry Reding wrote:
> Today's linux-next merge of the omap_dss2 tree got conflicts in
> 
> 	drivers/video/omap2/dss/hdmi4_core.c
> 	drivers/video/omap2/dss/hdmi4_core.h
> 
> caused by commits ef26958 (omapdss: HDMI: Rename hdmi driver files to nicer
> names) and a few others that I didn't quite track down. But given that the
> diff of the merge commit is empty I guess everything's well.

Jean-Christophe has slightly different versions of my patches in his
fbdev for-next branch, so they conflict with my updated versions.

Jean-Christophe, I expected this to happen with the current way of you
having a copy of my for-next branch in yours. Can I now take your
atmel_lcdfb patches to my for-next, and you'll remove all patches from
your for-next?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: linux-next: manual merge of the omap_dss2 tree

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

Hi,

On 14/10/13 17:48, Thierry Reding wrote:
> Today's linux-next merge of the omap_dss2 tree got conflicts in
> 
> 	drivers/video/omap2/dss/hdmi4_core.c
> 	drivers/video/omap2/dss/hdmi4_core.h
> 
> caused by commits ef26958 (omapdss: HDMI: Rename hdmi driver files to nicer
> names) and a few others that I didn't quite track down. But given that the
> diff of the merge commit is empty I guess everything's well.

Jean-Christophe has slightly different versions of my patches in his
fbdev for-next branch, so they conflict with my updated versions.

Jean-Christophe, I expected this to happen with the current way of you
having a copy of my for-next branch in yours. Can I now take your
atmel_lcdfb patches to my for-next, and you'll remove all patches from
your for-next?

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

linux-next: manual merge of the pm tree

[Thierry Reding]

Today's linux-next merge of the pm tree (5d5e5df) got conflicts in

	drivers/i2c/i2c-core.c

caused by commits 0acc2b3 (i2c: Remove redundant 'driver' field from the
i2c_client struct) and a76e9bd (i2c: attach/detach I2C client device to
the ACPI power domain).

I fixed them up (see below). Please verify that the resolution looks
good.

Thanks,
Thierry
---
diff --cc drivers/i2c/i2c-core.c
index 111b2c6,03a8ae6..5923cfa
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@@ -254,10 -254,13 +254,12 @@@ static int i2c_device_probe(struct devi
  					client->flags & I2C_CLIENT_WAKE);
  	dev_dbg(dev, "probe\n");
  
+ 	acpi_dev_pm_attach(&client->dev, true);
  	status = driver->probe(client, i2c_match_id(driver->id_table, client));
- 	if (status)
+ 	if (status) {
 -		client->driver = NULL;
  		i2c_set_clientdata(client, NULL);
- 
+ 		acpi_dev_pm_detach(&client->dev, true);
+ 	}
  	return status;
  }
  
@@@ -278,9 -281,11 +280,9 @@@ static int i2c_device_remove(struct dev
  		dev->driver = NULL;
  		status = 0;
  	}
 -	if (status == 0) {
 -		client->driver = NULL;
 +	if (status == 0)
  		i2c_set_clientdata(client, NULL);
- 
 -	}
+ 	acpi_dev_pm_detach(&client->dev, true);
  	return status;
  }
  

linux-next: manual merge of the spi tree

[Thierry Reding]

Today's linux-next merge of the spi tree got a conflict in

	drivers/spi/spi.c

Caused by commits cf9eb39 (spi: Fix modalias for ACPI enumerated SPI devices)
and 33cf00e (spi: attach/detach SPI device to the ACPI power domain).

I fixed it up (see below). Please verify that the resolution looks good.

Thanks,
Thierry
---
diff --cc drivers/spi/spi.c
index 740f9dd,2d29dee..8a0fc92
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@@ -1037,10 -1143,8 +1155,10 @@@ static acpi_status acpi_spi_add_device(
  		return AE_OK;
  	}
  
 +	adev->power.flags.ignore_parent = true;
- 	strlcpy(spi->modalias, dev_name(&adev->dev), sizeof(spi->modalias));
+ 	strlcpy(spi->modalias, acpi_device_hid(adev), sizeof(spi->modalias));
  	if (spi_add_device(spi)) {
 +		adev->power.flags.ignore_parent = false;
  		dev_err(&master->dev, "failed to add SPI device %s from ACPI\n",
  			dev_name(&adev->dev));
  		spi_dev_put(spi);

Re: linux-next: manual merge of the spi tree

[Mika Westerberg]

On Mon, Oct 14, 2013 at 04:48:08PM +0200, Thierry Reding wrote:
> Today's linux-next merge of the spi tree got a conflict in
> 
> 	drivers/spi/spi.c
> 
> Caused by commits cf9eb39 (spi: Fix modalias for ACPI enumerated SPI devices)
> and 33cf00e (spi: attach/detach SPI device to the ACPI power domain).
> 
> I fixed it up (see below). Please verify that the resolution looks good.
> 
> Thanks,
> Thierry
> ---
> diff --cc drivers/spi/spi.c
> index 740f9dd,2d29dee..8a0fc92
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@@ -1037,10 -1143,8 +1155,10 @@@ static acpi_status acpi_spi_add_device(
>   		return AE_OK;
>   	}
>   
>  +	adev->power.flags.ignore_parent = true;
> - 	strlcpy(spi->modalias, dev_name(&adev->dev), sizeof(spi->modalias));
> + 	strlcpy(spi->modalias, acpi_device_hid(adev), sizeof(spi->modalias));
>   	if (spi_add_device(spi)) {
>  +		adev->power.flags.ignore_parent = false;
>   		dev_err(&master->dev, "failed to add SPI device %s from ACPI\n",
>   			dev_name(&adev->dev));
>   		spi_dev_put(spi);

Looks good to me, thanks!

Re: linux-next: Tree for Oct 14 (bcache)

[Randy Dunlap]

On 10/14/13 07:48, Thierry Reding wrote:
> Hi all,
> 
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
> 
>         git://gitorious.org/thierryreding/linux-next.git
> 
> A next-20131014 tag is also provided for convenience.
> 
> Gained a few conflicts, but nothing too exciting. x86 and ARM default
> configurations build fine. There were some build failures unrelated to

Maybe you could build allmodconfig instead of a default config
for more better coverage?  I am seeing lots of build problems.

> the merge, most of which I fixed and added as patches on top of the
> final merge.


on x86_64:

drivers/md/bcache/request.c: In function 'cached_dev_write':
drivers/md/bcache/request.c:1076:8: error: 'struct btree_op' has no member named 'cache_bio'


-- 
~Randy

Re: linux-next: Tree for Oct 14 (bcache)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On Mon, Oct 14, 2013 at 11:58:10AM -0700, Randy Dunlap wrote:
> On 10/14/13 07:48, Thierry Reding wrote:

> > Gained a few conflicts, but nothing too exciting. x86 and ARM default
> > configurations build fine. There were some build failures unrelated to

> Maybe you could build allmodconfig instead of a default config
> for more better coverage?  I am seeing lots of build problems.

I'd say in addition - if you look at the last tree I did it's got fixes
for all these tihngs I think.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: Tree for Oct 14 (bcache)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Mon, Oct 14, 2013 at 09:27:23PM +0100, Mark Brown wrote:
> On Mon, Oct 14, 2013 at 11:58:10AM -0700, Randy Dunlap wrote:
> > On 10/14/13 07:48, Thierry Reding wrote:
> 
> > > Gained a few conflicts, but nothing too exciting. x86 and ARM default
> > > configurations build fine. There were some build failures unrelated to
> 
> > Maybe you could build allmodconfig instead of a default config
> > for more better coverage?  I am seeing lots of build problems.
> 
> I'd say in addition - if you look at the last tree I did it's got fixes
> for all these tihngs I think.

Strange, I didn't see any build fixes in it.

Oh wait, they were applied right after the merges that broke. I hadn't
checked for that.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: Tree for Oct 14 (bcache)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Mon, Oct 14, 2013 at 09:27:23PM +0100, Mark Brown wrote:
> On Mon, Oct 14, 2013 at 11:58:10AM -0700, Randy Dunlap wrote:
> > On 10/14/13 07:48, Thierry Reding wrote:
> 
> > > Gained a few conflicts, but nothing too exciting. x86 and ARM default
> > > configurations build fine. There were some build failures unrelated to
> 
> > Maybe you could build allmodconfig instead of a default config
> > for more better coverage?  I am seeing lots of build problems.
> 
> I'd say in addition - if you look at the last tree I did it's got fixes
> for all these tihngs I think.

Strange, I didn't see any build fixes in it.

Oh wait, they were applied right after the merges that broke. I hadn't
checked for that.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: Tree for Oct 14 (bcache)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

On Tue, Oct 15, 2013 at 10:46:32AM +0200, Thierry Reding wrote:

> Oh wait, they were applied right after the merges that broke. I hadn't
> checked for that.

Yeah, it's because I've been doing incremental build checks - the builds
fail at the point the tree gets merged in.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: Tree for Oct 14 (bcache)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

On Tue, Oct 15, 2013 at 10:46:32AM +0200, Thierry Reding wrote:

> Oh wait, they were applied right after the merges that broke. I hadn't
> checked for that.

Yeah, it's because I've been doing incremental build checks - the builds
fail at the point the tree gets merged in.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: Tree for Oct 14 (bcache)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

On Mon, Oct 14, 2013 at 11:58:10AM -0700, Randy Dunlap wrote:
> On 10/14/13 07:48, Thierry Reding wrote:
> > Hi all,
> > 
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> > 
> >         git://gitorious.org/thierryreding/linux-next.git
> > 
> > A next-20131014 tag is also provided for convenience.
> > 
> > Gained a few conflicts, but nothing too exciting. x86 and ARM default
> > configurations build fine. There were some build failures unrelated to
> 
> Maybe you could build allmodconfig instead of a default config
> for more better coverage?  I am seeing lots of build problems.

Ideally I'd be able to run allmodconfig for each merge, but I have
neither the computing power nor the time to do that. I can add
allmodconfig to the set of configurations that I build after the final
merge, but I don't know how much good that is if I don't actually have
any time to fix them up.

Furthermore I'm beginning to think that perhaps we should create some
infrastructure around this that would make it easier to submit requests
for build coverage. Quite a few people seem to run autobuilders, so if
all those could be harnessed to build linux-next (perhaps even on a per
merge basis) that would give great coverage.

> > the merge, most of which I fixed and added as patches on top of the
> > final merge.
> 
> 
> on x86_64:
> 
> drivers/md/bcache/request.c: In function 'cached_dev_write':
> drivers/md/bcache/request.c:1076:8: error: 'struct btree_op' has no member named 'cache_bio'

It's quite possible that I messed that up during the merge. The bcache
conflicts weren't very trivial. This one in particular seems to be
caused by a commit that went into 3.12-rc5 and one in the block tree's
linux-next branch.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: Tree for Oct 14 (bcache)

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

On Mon, Oct 14, 2013 at 11:58:10AM -0700, Randy Dunlap wrote:
> On 10/14/13 07:48, Thierry Reding wrote:
> > Hi all,
> > 
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> > 
> >         git://gitorious.org/thierryreding/linux-next.git
> > 
> > A next-20131014 tag is also provided for convenience.
> > 
> > Gained a few conflicts, but nothing too exciting. x86 and ARM default
> > configurations build fine. There were some build failures unrelated to
> 
> Maybe you could build allmodconfig instead of a default config
> for more better coverage?  I am seeing lots of build problems.

Ideally I'd be able to run allmodconfig for each merge, but I have
neither the computing power nor the time to do that. I can add
allmodconfig to the set of configurations that I build after the final
merge, but I don't know how much good that is if I don't actually have
any time to fix them up.

Furthermore I'm beginning to think that perhaps we should create some
infrastructure around this that would make it easier to submit requests
for build coverage. Quite a few people seem to run autobuilders, so if
all those could be harnessed to build linux-next (perhaps even on a per
merge basis) that would give great coverage.

> > the merge, most of which I fixed and added as patches on top of the
> > final merge.
> 
> 
> on x86_64:
> 
> drivers/md/bcache/request.c: In function 'cached_dev_write':
> drivers/md/bcache/request.c:1076:8: error: 'struct btree_op' has no member named 'cache_bio'

It's quite possible that I messed that up during the merge. The bcache
conflicts weren't very trivial. This one in particular seems to be
caused by a commit that went into 3.12-rc5 and one in the block tree's
linux-next branch.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH -next] netdev: inet_timewait_sock.h missing semi-colon when KMEMCHECK is enabled

[Randy Dunlap]

From: Randy Dunlap <rdunlap@infradead.org>

Fix (a few hundred) build errors due to missing semi-colon when
KMEMCHECK is enabled:

  include/net/inet_timewait_sock.h:139:2: error: expected ',', ';' or '}' before 'int'
  include/net/inet_timewait_sock.h:148:28: error: 'const struct inet_timewait_sock' has no member named 'tw_death_node'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
 include/net/inet_timewait_sock.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- next-2013-1014.orig/include/net/inet_timewait_sock.h
+++ next-2013-1014/include/net/inet_timewait_sock.h
@@ -135,7 +135,7 @@ struct inet_timewait_sock {
 				tw_transparent  : 1,
 				tw_pad		: 6,	/* 6 bits hole */
 				tw_tos		: 8,
-				tw_pad2		: 16 /* 16 bits hole */
+				tw_pad2		: 16;	/* 16 bits hole */
 	kmemcheck_bitfield_end(flags);
 	u32			tw_ttd;
 	struct inet_bind_bucket	*tw_tb;

Re: [PATCH -next] netdev: inet_timewait_sock.h missing semi-colon when KMEMCHECK is enabled

[Joe Perches]

On Mon, 2013-10-14 at 12:36 -0700, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
> 
> Fix (a few hundred) build errors due to missing semi-colon when
> KMEMCHECK is enabled:
> 
>   include/net/inet_timewait_sock.h:139:2: error: expected ',', ';' or '}' before 'int'
>   include/net/inet_timewait_sock.h:148:28: error: 'const struct inet_timewait_sock' has no member named 'tw_death_node'
> 
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
>  include/net/inet_timewait_sock.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- next-2013-1014.orig/include/net/inet_timewait_sock.h
> +++ next-2013-1014/include/net/inet_timewait_sock.h
> @@ -135,7 +135,7 @@ struct inet_timewait_sock {
>  				tw_transparent  : 1,
>  				tw_pad		: 6,	/* 6 bits hole */
>  				tw_tos		: 8,
> -				tw_pad2		: 16 /* 16 bits hole */
> +				tw_pad2		: 16;	/* 16 bits hole */
>  	kmemcheck_bitfield_end(flags);
>  	u32			tw_ttd;
>  	struct inet_bind_bucket	*tw_tb;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Shouldn't this be done in kmemcheck.h?

 include/linux/kmemcheck.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/kmemcheck.h b/include/linux/kmemcheck.h
index 39f8453..b9ffad5 100644
--- a/include/linux/kmemcheck.h
+++ b/include/linux/kmemcheck.h
@@ -62,10 +62,10 @@ bool kmemcheck_is_obj_initialized(unsigned long addr, size_t size);
  *     kmemcheck_annotate_bitfield(a, flags);
  */
 #define kmemcheck_bitfield_begin(name)	\
-	int name##_begin[0];
+	int name##_begin[0]
 
 #define kmemcheck_bitfield_end(name)	\
-	int name##_end[0];
+	int name##_end[0]
 
 #define kmemcheck_annotate_bitfield(ptr, name)				\
 	do {								\

Re: [PATCH -next] netdev: inet_timewait_sock.h missing semi-colon when KMEMCHECK is enabled

[Randy Dunlap]

On 10/14/13 12:53, Joe Perches wrote:
> On Mon, 2013-10-14 at 12:36 -0700, Randy Dunlap wrote:
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> Fix (a few hundred) build errors due to missing semi-colon when
>> KMEMCHECK is enabled:
>>
>>   include/net/inet_timewait_sock.h:139:2: error: expected ',', ';' or '}' before 'int'
>>   include/net/inet_timewait_sock.h:148:28: error: 'const struct inet_timewait_sock' has no member named 'tw_death_node'
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> ---
>>  include/net/inet_timewait_sock.h |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> --- next-2013-1014.orig/include/net/inet_timewait_sock.h
>> +++ next-2013-1014/include/net/inet_timewait_sock.h
>> @@ -135,7 +135,7 @@ struct inet_timewait_sock {
>>  				tw_transparent  : 1,
>>  				tw_pad		: 6,	/* 6 bits hole */
>>  				tw_tos		: 8,
>> -				tw_pad2		: 16 /* 16 bits hole */
>> +				tw_pad2		: 16;	/* 16 bits hole */
>>  	kmemcheck_bitfield_end(flags);
>>  	u32			tw_ttd;
>>  	struct inet_bind_bucket	*tw_tb;
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 
> Shouldn't this be done in kmemcheck.h?

This patch makes sense and probably should be merged
but it does not fix the build errors that I reported.


>  include/linux/kmemcheck.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/kmemcheck.h b/include/linux/kmemcheck.h
> index 39f8453..b9ffad5 100644
> --- a/include/linux/kmemcheck.h
> +++ b/include/linux/kmemcheck.h
> @@ -62,10 +62,10 @@ bool kmemcheck_is_obj_initialized(unsigned long addr, size_t size);
>   *     kmemcheck_annotate_bitfield(a, flags);
>   */
>  #define kmemcheck_bitfield_begin(name)	\
> -	int name##_begin[0];
> +	int name##_begin[0]
>  
>  #define kmemcheck_bitfield_end(name)	\
> -	int name##_end[0];
> +	int name##_end[0]
>  
>  #define kmemcheck_annotate_bitfield(ptr, name)				\
>  	do {								\
> 
> 
> --



-- 
~Randy

Re: [PATCH -next] netdev: inet_timewait_sock.h missing semi-colon when KMEMCHECK is enabled

[Joe Perches]

On Mon, 2013-10-14 at 13:47 -0700, Randy Dunlap wrote:
> On 10/14/13 12:53, Joe Perches wrote:
> > On Mon, 2013-10-14 at 12:36 -0700, Randy Dunlap wrote:
> >> From: Randy Dunlap <rdunlap@infradead.org>
> >>
> >> Fix (a few hundred) build errors due to missing semi-colon when
> >> KMEMCHECK is enabled:
> >>
> >>   include/net/inet_timewait_sock.h:139:2: error: expected ',', ';' or '}' before 'int'
> >>   include/net/inet_timewait_sock.h:148:28: error: 'const struct inet_timewait_sock' has no member named 'tw_death_node'
> >>
> >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> >> ---
> >>  include/net/inet_timewait_sock.h |    2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> --- next-2013-1014.orig/include/net/inet_timewait_sock.h
> >> +++ next-2013-1014/include/net/inet_timewait_sock.h
> >> @@ -135,7 +135,7 @@ struct inet_timewait_sock {
> >>  				tw_transparent  : 1,
> >>  				tw_pad		: 6,	/* 6 bits hole */
> >>  				tw_tos		: 8,
> >> -				tw_pad2		: 16 /* 16 bits hole */
> >> +				tw_pad2		: 16;	/* 16 bits hole */
> >>  	kmemcheck_bitfield_end(flags);
> >>  	u32			tw_ttd;
> >>  	struct inet_bind_bucket	*tw_tb;
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > Shouldn't this be done in kmemcheck.h?
> 
> This patch makes sense and probably should be merged
> but it does not fix the build errors that I reported.

You sure?

Re: [PATCH -next] netdev: inet_timewait_sock.h missing semi-colon when KMEMCHECK is enabled

[Joe Perches]

On Mon, 2013-10-14 at 13:47 -0700, Randy Dunlap wrote:
> On 10/14/13 12:53, Joe Perches wrote:
> > On Mon, 2013-10-14 at 12:36 -0700, Randy Dunlap wrote:
> >> From: Randy Dunlap <rdunlap@infradead.org>
> >>
> >> Fix (a few hundred) build errors due to missing semi-colon when
> >> KMEMCHECK is enabled:

keyword: enabled...

> > Shouldn't this be done in kmemcheck.h?
> 
> This patch makes sense and probably should be merged
> but it does not fix the build errors that I reported.

Duh, enabled.  Yeah, you're sure...

Re: [PATCH -next] netdev: inet_timewait_sock.h missing semi-colon when KMEMCHECK is enabled

[David Miller]

From: Randy Dunlap <rdunlap@infradead.org>
Date: Mon, 14 Oct 2013 12:36:32 -0700

> From: Randy Dunlap <rdunlap@infradead.org>
> 
> Fix (a few hundred) build errors due to missing semi-colon when
> KMEMCHECK is enabled:
> 
>   include/net/inet_timewait_sock.h:139:2: error: expected ',', ';' or '}' before 'int'
>   include/net/inet_timewait_sock.h:148:28: error: 'const struct inet_timewait_sock' has no member named 'tw_death_node'
> 
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>

Applied, thanks Randy.

[PATCH -next] misc: fix various misc/mic/host/ build errors

[Randy Dunlap]

From: Randy Dunlap <rdunlap@infradead.org>

Fix various build errors (on x86_64) for drivers/misc/mic/host/:

  drivers/misc/mic/host/mic_main.c:378:3: error: too many arguments to function 'sysfs_get_dirent'
  drivers/misc/mic/host/mic_intr.h:134:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
  drivers/misc/mic/host/mic_intr.h:134:58: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
  drivers/misc/mic/host/mic_intr.h:135:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
  drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
  drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_read':
  drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
  drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_write':
  drivers/misc/mic/host/mic_device.h:183:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Nikhil Rao <nikhil.rao@intel.com>
Cc: Sudeep Dutt <sudeep.dutt@intel.com>
---
 drivers/misc/mic/host/mic_device.h |    1 +
 drivers/misc/mic/host/mic_intr.h   |    1 +
 drivers/misc/mic/host/mic_main.c   |    3 +--
 3 files changed, 3 insertions(+), 2 deletions(-)

--- next-2013-1014.orig/drivers/misc/mic/host/mic_main.c
+++ next-2013-1014/drivers/misc/mic/host/mic_main.c
@@ -374,8 +374,7 @@ static int mic_probe(struct pci_dev *pde
 			"device_create_with_groups failed rc %d\n", rc);
 		goto smpt_uninit;
 	}
-	mdev->state_sysfs = sysfs_get_dirent(mdev->sdev->kobj.sd,
-		NULL, "state");
+	mdev->state_sysfs = sysfs_get_dirent(mdev->sdev->kobj.sd, "state");
 	if (!mdev->state_sysfs) {
 		rc = -ENODEV;
 		dev_err(&pdev->dev, "sysfs_get_dirent failed rc %d\n", rc);
--- next-2013-1014.orig/drivers/misc/mic/host/mic_device.h
+++ next-2013-1014/drivers/misc/mic/host/mic_device.h
@@ -24,6 +24,7 @@
 #include <linux/cdev.h>
 #include <linux/idr.h>
 #include <linux/notifier.h>
+#include <asm-generic/iomap.h>
 
 #include "mic_intr.h"
 
--- next-2013-1014.orig/drivers/misc/mic/host/mic_intr.h
+++ next-2013-1014/drivers/misc/mic/host/mic_intr.h
@@ -131,6 +131,7 @@ struct mic_irq *mic_request_irq(struct m
 
 void mic_free_irq(struct mic_device *mdev,
 		struct mic_irq *cookie, void *data);
+struct pci_dev;
 int mic_setup_interrupts(struct mic_device *mdev, struct pci_dev *pdev);
 void mic_free_interrupts(struct mic_device *mdev, struct pci_dev *pdev);
 void mic_intr_restore(struct mic_device *mdev);

Re: [PATCH -next] misc: fix various misc/mic/host/ build errors

[Greg Kroah-Hartman]

On Mon, Oct 14, 2013 at 12:38:06PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
> 
> Fix various build errors (on x86_64) for drivers/misc/mic/host/:
> 
>   drivers/misc/mic/host/mic_main.c:378:3: error: too many arguments to function 'sysfs_get_dirent'
>   drivers/misc/mic/host/mic_intr.h:134:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
>   drivers/misc/mic/host/mic_intr.h:134:58: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
>   drivers/misc/mic/host/mic_intr.h:135:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_read':
>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_write':
>   drivers/misc/mic/host/mic_device.h:183:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> 
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>
> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Nikhil Rao <nikhil.rao@intel.com>
> Cc: Sudeep Dutt <sudeep.dutt@intel.com>

This is a -next issue only at this point in time, I thought it was in
the -next tree as a "fixup" already?

Re: [PATCH -next] misc: fix various misc/mic/host/ build errors

[Randy Dunlap]

On 10/16/13 12:26, Greg Kroah-Hartman wrote:
> On Mon, Oct 14, 2013 at 12:38:06PM -0700, Randy Dunlap wrote:
>> From: Randy Dunlap <rdunlap@infradead.org>
>>
>> Fix various build errors (on x86_64) for drivers/misc/mic/host/:
>>
>>   drivers/misc/mic/host/mic_main.c:378:3: error: too many arguments to function 'sysfs_get_dirent'
>>   drivers/misc/mic/host/mic_intr.h:134:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
>>   drivers/misc/mic/host/mic_intr.h:134:58: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
>>   drivers/misc/mic/host/mic_intr.h:135:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
>>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
>>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_read':
>>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
>>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_write':
>>   drivers/misc/mic/host/mic_device.h:183:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
>>
>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
>> Cc: Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>
>> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Nikhil Rao <nikhil.rao@intel.com>
>> Cc: Sudeep Dutt <sudeep.dutt@intel.com>
> 
> This is a -next issue only at this point in time, I thought it was in
> the -next tree as a "fixup" already?

Are you asking the driver maintainers?

-- 
~Randy

Re: [PATCH -next] misc: fix various misc/mic/host/ build errors

[Greg Kroah-Hartman]

On Wed, Oct 16, 2013 at 12:41:08PM -0700, Randy Dunlap wrote:
> On 10/16/13 12:26, Greg Kroah-Hartman wrote:
> > On Mon, Oct 14, 2013 at 12:38:06PM -0700, Randy Dunlap wrote:
> >> From: Randy Dunlap <rdunlap@infradead.org>
> >>
> >> Fix various build errors (on x86_64) for drivers/misc/mic/host/:
> >>
> >>   drivers/misc/mic/host/mic_main.c:378:3: error: too many arguments to function 'sysfs_get_dirent'
> >>   drivers/misc/mic/host/mic_intr.h:134:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
> >>   drivers/misc/mic/host/mic_intr.h:134:58: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> >>   drivers/misc/mic/host/mic_intr.h:135:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
> >>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> >>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_read':
> >>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> >>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_write':
> >>   drivers/misc/mic/host/mic_device.h:183:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> >>
> >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> >> Cc: Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>
> >> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >> Cc: Nikhil Rao <nikhil.rao@intel.com>
> >> Cc: Sudeep Dutt <sudeep.dutt@intel.com>
> > 
> > This is a -next issue only at this point in time, I thought it was in
> > the -next tree as a "fixup" already?
> 
> Are you asking the driver maintainers?

No, the linux-next maintainers.

The driver maintainers have nothing to do with this, it's a sysfs change
in my driver-core tree that causes this issue.

thanks,

greg k-h

Re: [PATCH -next] misc: fix various misc/mic/host/ build errors

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2752 bytes --]

On Wed, Oct 16, 2013 at 12:44:40PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 16, 2013 at 12:41:08PM -0700, Randy Dunlap wrote:
> > On 10/16/13 12:26, Greg Kroah-Hartman wrote:
> > > On Mon, Oct 14, 2013 at 12:38:06PM -0700, Randy Dunlap wrote:
> > >> From: Randy Dunlap <rdunlap@infradead.org>
> > >>
> > >> Fix various build errors (on x86_64) for drivers/misc/mic/host/:
> > >>
> > >>   drivers/misc/mic/host/mic_main.c:378:3: error: too many arguments to function 'sysfs_get_dirent'
> > >>   drivers/misc/mic/host/mic_intr.h:134:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
> > >>   drivers/misc/mic/host/mic_intr.h:134:58: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> > >>   drivers/misc/mic/host/mic_intr.h:135:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
> > >>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > >>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_read':
> > >>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > >>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_write':
> > >>   drivers/misc/mic/host/mic_device.h:183:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > >>
> > >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> > >> Cc: Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>
> > >> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >> Cc: Nikhil Rao <nikhil.rao@intel.com>
> > >> Cc: Sudeep Dutt <sudeep.dutt@intel.com>
> > > 
> > > This is a -next issue only at this point in time, I thought it was in
> > > the -next tree as a "fixup" already?
> > 
> > Are you asking the driver maintainers?
> 
> No, the linux-next maintainers.
> 
> The driver maintainers have nothing to do with this, it's a sysfs change
> in my driver-core tree that causes this issue.

Well, we do carry a patch to fix this, but that generally doesn't get
carried to Linus' tree automatically as far as I know. So I guess it's
fine for now, but when the merge window opens you'll need to make sure
that Linus merges the branches in the correct order so that the build
doesn't break in between.

I think the typical way to solve this kind of build dependencies between
trees is for one tree to provide a stable branch that can be merged into
the other. That ensures that each tree can still be built independently.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH -next] misc: fix various misc/mic/host/ build errors

[Greg Kroah-Hartman]

On Wed, Oct 16, 2013 at 10:30:25PM +0200, Thierry Reding wrote:
> On Wed, Oct 16, 2013 at 12:44:40PM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Oct 16, 2013 at 12:41:08PM -0700, Randy Dunlap wrote:
> > > On 10/16/13 12:26, Greg Kroah-Hartman wrote:
> > > > On Mon, Oct 14, 2013 at 12:38:06PM -0700, Randy Dunlap wrote:
> > > >> From: Randy Dunlap <rdunlap@infradead.org>
> > > >>
> > > >> Fix various build errors (on x86_64) for drivers/misc/mic/host/:
> > > >>
> > > >>   drivers/misc/mic/host/mic_main.c:378:3: error: too many arguments to function 'sysfs_get_dirent'
> > > >>   drivers/misc/mic/host/mic_intr.h:134:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
> > > >>   drivers/misc/mic/host/mic_intr.h:134:58: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> > > >>   drivers/misc/mic/host/mic_intr.h:135:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
> > > >>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > > >>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_read':
> > > >>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > > >>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_write':
> > > >>   drivers/misc/mic/host/mic_device.h:183:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > > >>
> > > >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> > > >> Cc: Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>
> > > >> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > > >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > >> Cc: Nikhil Rao <nikhil.rao@intel.com>
> > > >> Cc: Sudeep Dutt <sudeep.dutt@intel.com>
> > > > 
> > > > This is a -next issue only at this point in time, I thought it was in
> > > > the -next tree as a "fixup" already?
> > > 
> > > Are you asking the driver maintainers?
> > 
> > No, the linux-next maintainers.
> > 
> > The driver maintainers have nothing to do with this, it's a sysfs change
> > in my driver-core tree that causes this issue.
> 
> Well, we do carry a patch to fix this, but that generally doesn't get
> carried to Linus' tree automatically as far as I know. So I guess it's
> fine for now, but when the merge window opens you'll need to make sure
> that Linus merges the branches in the correct order so that the build
> doesn't break in between.

Yes, I'll do that as part of my normal tree submission process.

> I think the typical way to solve this kind of build dependencies between
> trees is for one tree to provide a stable branch that can be merged into
> the other. That ensures that each tree can still be built independently.

I don't do that for my different trees, sorry, especially for staging
drivers, they can break all the time, no one really cares :)

thanks,

greg k-h

Re: [PATCH -next] misc: fix various misc/mic/host/ build errors

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]

On Wed, Oct 16, 2013 at 01:37:27PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 16, 2013 at 10:30:25PM +0200, Thierry Reding wrote:
> > On Wed, Oct 16, 2013 at 12:44:40PM -0700, Greg Kroah-Hartman wrote:
> > > On Wed, Oct 16, 2013 at 12:41:08PM -0700, Randy Dunlap wrote:
> > > > On 10/16/13 12:26, Greg Kroah-Hartman wrote:
> > > > > On Mon, Oct 14, 2013 at 12:38:06PM -0700, Randy Dunlap wrote:
> > > > >> From: Randy Dunlap <rdunlap@infradead.org>
> > > > >>
> > > > >> Fix various build errors (on x86_64) for drivers/misc/mic/host/:
> > > > >>
> > > > >>   drivers/misc/mic/host/mic_main.c:378:3: error: too many arguments to function 'sysfs_get_dirent'
> > > > >>   drivers/misc/mic/host/mic_intr.h:134:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
> > > > >>   drivers/misc/mic/host/mic_intr.h:134:58: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> > > > >>   drivers/misc/mic/host/mic_intr.h:135:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
> > > > >>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > > > >>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_read':
> > > > >>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > > > >>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_write':
> > > > >>   drivers/misc/mic/host/mic_device.h:183:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > > > >>
> > > > >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> > > > >> Cc: Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>
> > > > >> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > > > >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > >> Cc: Nikhil Rao <nikhil.rao@intel.com>
> > > > >> Cc: Sudeep Dutt <sudeep.dutt@intel.com>
> > > > > 
> > > > > This is a -next issue only at this point in time, I thought it was in
> > > > > the -next tree as a "fixup" already?
> > > > 
> > > > Are you asking the driver maintainers?
> > > 
> > > No, the linux-next maintainers.
> > > 
> > > The driver maintainers have nothing to do with this, it's a sysfs change
> > > in my driver-core tree that causes this issue.
> > 
> > Well, we do carry a patch to fix this, but that generally doesn't get
> > carried to Linus' tree automatically as far as I know. So I guess it's
> > fine for now, but when the merge window opens you'll need to make sure
> > that Linus merges the branches in the correct order so that the build
> > doesn't break in between.
> 
> Yes, I'll do that as part of my normal tree submission process.

Actually, ensuring correct merge order won't be enough, will it? That
doesn't magically fixes that the function's signature actually changed.

Shouldn't the update of the sysfs_get_dirent() call be fixed within the
same patch that updates the sysfs_get_dirent() signature?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH -next] misc: fix various misc/mic/host/ build errors

[Greg Kroah-Hartman]

On Thu, Oct 17, 2013 at 04:02:25PM +0200, Thierry Reding wrote:
> On Wed, Oct 16, 2013 at 01:37:27PM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Oct 16, 2013 at 10:30:25PM +0200, Thierry Reding wrote:
> > > On Wed, Oct 16, 2013 at 12:44:40PM -0700, Greg Kroah-Hartman wrote:
> > > > On Wed, Oct 16, 2013 at 12:41:08PM -0700, Randy Dunlap wrote:
> > > > > On 10/16/13 12:26, Greg Kroah-Hartman wrote:
> > > > > > On Mon, Oct 14, 2013 at 12:38:06PM -0700, Randy Dunlap wrote:
> > > > > >> From: Randy Dunlap <rdunlap@infradead.org>
> > > > > >>
> > > > > >> Fix various build errors (on x86_64) for drivers/misc/mic/host/:
> > > > > >>
> > > > > >>   drivers/misc/mic/host/mic_main.c:378:3: error: too many arguments to function 'sysfs_get_dirent'
> > > > > >>   drivers/misc/mic/host/mic_intr.h:134:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
> > > > > >>   drivers/misc/mic/host/mic_intr.h:134:58: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> > > > > >>   drivers/misc/mic/host/mic_intr.h:135:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
> > > > > >>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > > > > >>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_read':
> > > > > >>   drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration]
> > > > > >>   drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_write':
> > > > > >>   drivers/misc/mic/host/mic_device.h:183:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration]
> > > > > >>
> > > > > >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> > > > > >> Cc: Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>
> > > > > >> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > > > > >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > >> Cc: Nikhil Rao <nikhil.rao@intel.com>
> > > > > >> Cc: Sudeep Dutt <sudeep.dutt@intel.com>
> > > > > > 
> > > > > > This is a -next issue only at this point in time, I thought it was in
> > > > > > the -next tree as a "fixup" already?
> > > > > 
> > > > > Are you asking the driver maintainers?
> > > > 
> > > > No, the linux-next maintainers.
> > > > 
> > > > The driver maintainers have nothing to do with this, it's a sysfs change
> > > > in my driver-core tree that causes this issue.
> > > 
> > > Well, we do carry a patch to fix this, but that generally doesn't get
> > > carried to Linus' tree automatically as far as I know. So I guess it's
> > > fine for now, but when the merge window opens you'll need to make sure
> > > that Linus merges the branches in the correct order so that the build
> > > doesn't break in between.
> > 
> > Yes, I'll do that as part of my normal tree submission process.
> 
> Actually, ensuring correct merge order won't be enough, will it? That
> doesn't magically fixes that the function's signature actually changed.
> 
> Shouldn't the update of the sysfs_get_dirent() call be fixed within the
> same patch that updates the sysfs_get_dirent() signature?

Yes, _if_ those files are actually part of that tree, but they aren't
(they got added in my staging-next tree, while these sysfs changes are
in my driver-next tree.)

So the trees on their own build just fine, it's only when you merge them
that there is an issue.  This happens all the time when apis change,
nothing new here...

greg k-h

Re: [PATCH -next] misc: fix various misc/mic/host/ build errors

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

On Thu, Oct 17, 2013 at 04:02:25PM +0200, Thierry Reding wrote:
> On Wed, Oct 16, 2013 at 01:37:27PM -0700, Greg Kroah-Hartman wrote:

> > Yes, I'll do that as part of my normal tree submission process.

> Actually, ensuring correct merge order won't be enough, will it? That
> doesn't magically fixes that the function's signature actually changed.

> Shouldn't the update of the sysfs_get_dirent() call be fixed within the
> same patch that updates the sysfs_get_dirent() signature?

They're applied in different trees so they're both OK by themselves,
it's the merge that brings the two together that needs to do the fixup.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH -next] misc: fix various misc/mic/host/ build errors

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

On Thu, Oct 17, 2013 at 03:16:29PM +0100, Mark Brown wrote:
> On Thu, Oct 17, 2013 at 04:02:25PM +0200, Thierry Reding wrote:
> > On Wed, Oct 16, 2013 at 01:37:27PM -0700, Greg Kroah-Hartman wrote:
> 
> > > Yes, I'll do that as part of my normal tree submission process.
> 
> > Actually, ensuring correct merge order won't be enough, will it? That
> > doesn't magically fixes that the function's signature actually changed.
> 
> > Shouldn't the update of the sysfs_get_dirent() call be fixed within the
> > same patch that updates the sysfs_get_dirent() signature?
> 
> They're applied in different trees so they're both OK by themselves,
> it's the merge that brings the two together that needs to do the fixup.

Right, as long as the person doing that merge remembers to do that. It
sounds like the thing that could easily be forgotten. But Linus has been
doing this for a long time, so I'm sure he'll know what to look for. I'm
curious though, are maintainers supposed to mention it when sending pull
requests with such a dependency?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH -next] misc: fix various misc/mic/host/ build errors

[Greg Kroah-Hartman]

On Thu, Oct 17, 2013 at 04:21:39PM +0200, Thierry Reding wrote:
> On Thu, Oct 17, 2013 at 03:16:29PM +0100, Mark Brown wrote:
> > On Thu, Oct 17, 2013 at 04:02:25PM +0200, Thierry Reding wrote:
> > > On Wed, Oct 16, 2013 at 01:37:27PM -0700, Greg Kroah-Hartman wrote:
> > 
> > > > Yes, I'll do that as part of my normal tree submission process.
> > 
> > > Actually, ensuring correct merge order won't be enough, will it? That
> > > doesn't magically fixes that the function's signature actually changed.
> > 
> > > Shouldn't the update of the sysfs_get_dirent() call be fixed within the
> > > same patch that updates the sysfs_get_dirent() signature?
> > 
> > They're applied in different trees so they're both OK by themselves,
> > it's the merge that brings the two together that needs to do the fixup.
> 
> Right, as long as the person doing that merge remembers to do that. It
> sounds like the thing that could easily be forgotten. But Linus has been
> doing this for a long time, so I'm sure he'll know what to look for. I'm
> curious though, are maintainers supposed to mention it when sending pull
> requests with such a dependency?

Sometimes, if we remember, we do, sometimes we don't :)

Re: [PATCH -next] misc: fix various misc/mic/host/ build errors

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

On Wed, Oct 16, 2013 at 10:30:25PM +0200, Thierry Reding wrote:
> On Wed, Oct 16, 2013 at 12:44:40PM -0700, Greg Kroah-Hartman wrote:

> > The driver maintainers have nothing to do with this, it's a sysfs change
> > in my driver-core tree that causes this issue.

> Well, we do carry a patch to fix this, but that generally doesn't get
> carried to Linus' tree automatically as far as I know. So I guess it's
> fine for now, but when the merge window opens you'll need to make sure

Yeah.  This one was one of the ones that went AWOL for a few days due to
being in the middle of the trees I'd produced (due to me doing the
merges).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH -next] staging/mt29f_spinand: fix build error when ONDIEECC not enabled

[Randy Dunlap]

From: Randy Dunlap <rdunlap@infradead.org>

Fix build error when CONFIG_MTD_SPINAND_ONDIEECC is not enabled
by moving an inline function outside of that #ifdef block.

drivers/staging/mt29f_spinand/mt29f_spinand.c: In function 'spinand_read_byte':
drivers/staging/mt29f_spinand/mt29f_spinand.c:665:9: error: implicit declaration of function 'mtd_to_state' [-Werror=implicit-function-declaration]
drivers/staging/mt29f_spinand/mt29f_spinand.c:665:32: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/staging/mt29f_spinand/mt29f_spinand.c: In function 'spinand_write_buf':
drivers/staging/mt29f_spinand/mt29f_spinand.c:700:32: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/staging/mt29f_spinand/mt29f_spinand.c: In function 'spinand_read_buf':
drivers/staging/mt29f_spinand/mt29f_spinand.c:707:32: warning: initialization makes pointer from integer without a cast [enabled by default]

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Kamlakant Patel <kamlakant.patel@broadcom.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mona Anonuevo <manonuevo@micron.com>
Cc: linux-mtd@lists.infradead.org
---
 drivers/staging/mt29f_spinand/mt29f_spinand.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- next-2013-1014.orig/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ next-2013-1014/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -28,9 +28,6 @@
 /*
  * OOB area specification layout:  Total 32 available free bytes.
  */
-#ifdef CONFIG_MTD_SPINAND_ONDIEECC
-static int enable_hw_ecc;
-static int enable_read_hw_ecc;
 
 static inline struct spinand_state *mtd_to_state(struct mtd_info *mtd)
 {
@@ -41,6 +38,10 @@ static inline struct spinand_state *mtd_
 	return state;
 }
 
+#ifdef CONFIG_MTD_SPINAND_ONDIEECC
+static int enable_hw_ecc;
+static int enable_read_hw_ecc;
+
 static struct nand_ecclayout spinand_oob_64 = {
 	.eccbytes = 24,
 	.eccpos = {

[PATCH -next] staging/mt29f_spinand: fix build error when ONDIEECC not enabled

[Randy Dunlap]

From: Randy Dunlap <rdunlap@infradead.org>

Fix build error when CONFIG_MTD_SPINAND_ONDIEECC is not enabled
by moving an inline function outside of that #ifdef block.

drivers/staging/mt29f_spinand/mt29f_spinand.c: In function 'spinand_read_byte':
drivers/staging/mt29f_spinand/mt29f_spinand.c:665:9: error: implicit declaration of function 'mtd_to_state' [-Werror=implicit-function-declaration]
drivers/staging/mt29f_spinand/mt29f_spinand.c:665:32: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/staging/mt29f_spinand/mt29f_spinand.c: In function 'spinand_write_buf':
drivers/staging/mt29f_spinand/mt29f_spinand.c:700:32: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/staging/mt29f_spinand/mt29f_spinand.c: In function 'spinand_read_buf':
drivers/staging/mt29f_spinand/mt29f_spinand.c:707:32: warning: initialization makes pointer from integer without a cast [enabled by default]

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Kamlakant Patel <kamlakant.patel@broadcom.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mona Anonuevo <manonuevo@micron.com>
Cc: linux-mtd@lists.infradead.org
---
 drivers/staging/mt29f_spinand/mt29f_spinand.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- next-2013-1014.orig/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ next-2013-1014/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -28,9 +28,6 @@
 /*
  * OOB area specification layout:  Total 32 available free bytes.
  */
-#ifdef CONFIG_MTD_SPINAND_ONDIEECC
-static int enable_hw_ecc;
-static int enable_read_hw_ecc;
 
 static inline struct spinand_state *mtd_to_state(struct mtd_info *mtd)
 {
@@ -41,6 +38,10 @@ static inline struct spinand_state *mtd_
 	return state;
 }
 
+#ifdef CONFIG_MTD_SPINAND_ONDIEECC
+static int enable_hw_ecc;
+static int enable_read_hw_ecc;
+
 static struct nand_ecclayout spinand_oob_64 = {
 	.eccbytes = 24,
 	.eccpos = {

Re: linux-next: Tree for Oct 14 (ceph)

[Randy Dunlap]

On 10/14/13 07:48, Thierry Reding wrote:
> Hi all,
> 
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
> 
>         git://gitorious.org/thierryreding/linux-next.git
> 
> A next-20131014 tag is also provided for convenience.
> 
> Gained a few conflicts, but nothing too exciting. x86 and ARM default
> configurations build fine. There were some build failures unrelated to
> the merge, most of which I fixed and added as patches on top of the
> final merge.

on i386:

fs/ceph/file.c: In function 'ceph_sync_read':
fs/ceph/file.c:437:25: error: 'struct iov_iter' has no member named 'iov'
fs/ceph/file.c:438:18: error: 'struct iov_iter' has no member named 'iov'
fs/ceph/file.c:470:26: error: 'struct iov_iter' has no member named 'iov'
fs/ceph/file.c:472:9: error: 'struct iov_iter' has no member named 'iov'
fs/ceph/file.c:472:9: error: 'struct iov_iter' has no member named 'iov'
fs/ceph/file.c:472:9: warning: comparison of distinct pointer types lacks a cast [enabled by default]
fs/ceph/file.c: In function 'ceph_sync_direct_write':
fs/ceph/file.c:586:24: error: 'struct iov_iter' has no member named 'iov'
fs/ceph/file.c:587:14: error: 'struct iov_iter' has no member named 'iov'
fs/ceph/file.c: In function 'ceph_sync_write':
fs/ceph/file.c:737:18: warning: comparison of distinct pointer types lacks a cast [enabled by default]




-- 
~Randy